Issues, monitors, alerts and incidents

Belvador uses the same words as the rest of the industry, each with one meaning. This page says what each word means here and what Belvador does with it today.

From an error to an incident#

event ──grouped──► issue ──a rule matches──► alert messagecheck-in / ping / uptime result ──a monitor is broken──► monitor problem (open until it recovers)

• An event is one error report your app sent. Events are stored on your node.

• An issue groups events with the same cause, using the stack trace and a versioned grouping algorithm. An issue lives across many occurrences: it can be resolved, come back (regression) or spike (escalating). See Issues.

• A monitor is a rule about what must be true: a job runs on schedule, a ping URL is called, an endpoint answers, an SLO stays within budget. See Monitors, Uptime and SLOs.

• A monitor problem is one stretch of time when a monitor is broken — a missed run, a failed run, a down endpoint, an SLO burning too fast. It opens on its own and closes on its own when the monitor recovers. Other tools call this an alert; Belvador's app shows it on the monitor, check or SLO page.

• An alert message is what Belvador sends to your Telegram bot, Slack, email or webhook when an alert rule matches an issue event or a monitor problem.

Incident#

In the industry an incident is a piece of work that needs a person: someone acknowledges it, owns it and confirms recovery. Belvador does not have incidents with owners or acknowledgement yet. Today, issues and monitor problems are tracked separately and alert messages go to the destinations you choose.

Acknowledging is not recovering. Recovery means fresh evidence — the monitor passing again, the issue not coming back — not someone saying it is fixed.

Release and environment#

• A release is the version string your app sends with each event (release in init). Issues can be filtered by release, and source maps are matched by it.

• An environment (production, staging…) separates data from different deployments of the same app.

Unknown is not healthy#

When Belvador cannot see something — the node is offline, a region did not report, no event has ever arrived from a runtime — it says unknown or not verified, never green. A quiet project is not proof that errors are being sent: use the connection check.