self-hosted error monitor
English Português
Open the panel

Flows

the belt: where it comes in, what goes out, what is kept open the screen

What it is for

A flow is one belt: where the error comes in, how it is read, where it goes out, and how long it is kept. Each row on this screen is one assembled belt, and its own screen draws the whole path.

The five stages

  1. In. One of two families. Receiver is when someone sends to meulog: meulog (its own format), sentry (any Sentry SDK), otlp and otlp metricas (OpenTelemetry: errors and timing), desempenho (operation timing, for whoever does not use the Sentry SDK), mad except (the bug report madExcept uploads over HTTP, with no code in the application), log, csp (browser policy violation) and heartbeat. Collector is when meulog goes and fetches: imap (a mailbox), opensearch, loki and http.
  2. Read. The format translates what arrived into meulog fields: bug report (madExcept), json, plain text, mapped (you say which field is what), log group and expression.
  3. Store. This is the only stage you cannot swap: it is meulog writing the occurrence, computing the fingerprint and grouping.
  4. Out. Notifier (slack, teams, discord, telegram, google chat, email, pagerduty, webhook) and tracker (github, gitlab, jira), which opens a task instead of sending a message.
  5. Clean. How long this belt keeps what it brought. Retention per belt, not global: debug logs can go in seven days while a customer bug report stays for two years.
The difference between this screen and Parts

Here you assemble one belt, wiring the parts into each other. Under Parts and records you find every installed part, each with its own configuration, and no belt at all. A part is the what; the flow is the path.

Testing stage by stage

Five buttons, one per stage, and not one end-to-end test. Each stage fails for a different reason, and a "did not work" that does not say where is exactly the problem this screen exists to solve:

  • In: does the connection work, and does anything come?
  • Read: does the format understand what arrived?
  • Store: where does this land, and what does storing do to it?
  • Out: does the channel really receive it?
  • Clean: what would be deleted if it ran now?

Out sends a real message to the real channel. Clean deletes nothing: it only counts.

Orphan inputs

An input that is on but belongs to no belt shows up on the screen as an orphan, with an invitation to build the flow. It is not an error: receiving without a belt is allowed. But whoever receives without a belt has no retention and no configured output.

What you should see

The belt drawn out, each stage with what is wired into it, and what is missing in grey. If nothing ever passed through it, the screen says so.

A closed issue comes back here

meulog opens the task on GitHub or Jira when the error goes past the volume you set, and reopens it when the error regresses. Closing the task out there marks the error fixed here, hourly — without it there were two sources of truth about the same bug, and meulog's was the stale one, because the team works on GitHub.

Polling, not a webhook

A webhook requires GitHub to reach your installation, and meulog installs on closed intranets — the same reason Ollama is on the analyst list. Polling works in both cases and asks for no public address, no new secret and no open port. The price is an hour of latency, and closing an issue is not urgent. It is one request per pass, not one per error.

This direction only. Closing out there marks it fixed here; marking it fixed here does not close anyone's task — the team may be waiting on review, on a deploy or on the customer, and a robot closing the task in the middle of that is the kind of automation people switch off the next day.

The version the error counts as fixed from is the one shipping at the moment of the close, and it is written into the error's timeline. It is not decoration: it is the regression threshold — an occurrence on a later version reopens the error by itself, and meulog reopens the issue along with it.