self-hosted error monitor Open the panel

Parts and records

every installed plugin and where each one fits open the screen

What it is for

Every plugin meulog has, grouped by the stage it belongs to, with each one's configuration. This is the inventory; the flow is the assembly.

The families

The count of each one is on the screen and not here: a family grows by a file, and a number written in prose goes stale the day after.

  • Receiver: takes in what someone sends.
  • Fetcher: goes and fetches where the error already is.
  • Format: translates what arrived.
  • Symbols: reads the symbol map of a native executable, so a stack of addresses becomes file and line. Delphi and MSVC maps.
  • Drawing: draws what was stored — a stack, an execution log, JSON or XML. It is not picked: it looks at the content.
  • Analyst: the AI. Claude, OpenAI, Ollama (local) and compatible — any service that speaks the OpenAI dialect, such as Groq, OpenRouter, vLLM or Azure, without a plugin per vendor. The question asked is not here: it is an agent, which is a record and not a class.
  • Check: the question a watched URL asks. A plain GET, or the tax authority's status service with its certificate.
  • Forge: reads the code around the line that broke. GitHub, GitLab, Azure.
  • Notifier: tells people.
  • Tracker: opens a task.
  • Purge: deletes what passed its retention, one policy per kind of thing stored.

Turning a part on

Each part has its own fields. Passwords and tokens are hidden once saved: the screen shows that it is filled, not the value.

The Test button exists on almost all of them, and it does what it says: it sends the real message, runs the real query, really tries to authenticate. A configuration mistake shows up now, not in the middle of an incident.

What meulog decides for you

A part that is turned off does not appear in the integration pick lists. A part that is on but missing required configuration appears flagged: it is in the path, and it is not going to work.