Skip to main content

Alerts: Metric Reference

This page is the source of truth for the in-app Explain this panels on the organization Alerts page (/alerts). Each section is written once as a content partial under _explain/alerts/ and rendered both here and inside the app's info panel (scripts/build-explain.mjs compiles the registry).

Open-now KPIs and Alert Distribution ignore the time chip; windowed metrics and charts use the topbar range. Alerts History and Alerts Activity are distinct charts — titles follow the UI, not internal component names. Explorer detail Alerts tabs are out of scope.

Active Alerts​

How many alerts are open and actionable right now across the selected instances.

How it's calculated​

  • Served by GET /api/v1/alerts/query with pageSize: 1 — the KPI uses pagination.totalCount, not a cached strip.
  • Counts non-resolved alert rows (the backend's open scope). The list's default Active filter is narrower (New + Acknowledged only); this KPI matches the dashboard Alerts tile.
  • Muted alerts are excluded. The topbar instance filter applies; the time window does not — this is "open now", not "fired in the window".

Reading it​

Zero is the healthy baseline. When Active Alerts is high but Alerts Fired is quiet for the window, the backlog is older than the chip. Open the Open Alerts list to act; use Alerts History / Alerts Activity for how the load arrived.

Critical​

How many open alerts are at Critical severity right now.

How it's calculated​

  • Taken from the same un-windowed GET /api/v1/alerts/query summary as Active Alerts (summary.bySeverity.critical).
  • Counts open Critical rows only. Muted alerts are excluded. Instance filter applies; time window does not.

Reading it​

Treat this as the urgent slice of Active Alerts. A rising Critical count with a flat Active total means severity is concentrating, not just volume.

Avg. Resolution​

Mean time to resolve alerts that were raised in the selected time window and have since been resolved.

How it's calculated​

  • Served by GET /api/v1/alerts/history for the chart snapshot window (from / to / bucketSize from the topbar chip).
  • Uses averageResolutionMinutes from the history payload (shown as a duration), measured from each alert's creation to its resolved_at.
  • The window filters on when an alert was raised, not when it closed. An alert raised inside the window counts however long afterwards it resolved, and one raised before the window never counts even if it closed inside it.
  • Unlike the bucketed severity counts on this page, this figure has no severity filter, so Info and Best Practice alerts are included. Muted alerts are excluded.
  • Shows an empty value when nothing raised in the window has resolved yet.
  • Respects the topbar instance filter. This is windowed — unlike Active Alerts / Critical.

Reading it​

Pair with Resolution Time (median and p90 on the same source). A short average with a long p90 means a few outliers dominate the tail. Because the window selects by raise time, a freshly chosen short window can look optimistic: the slow alerts it contains have not resolved yet, so they are not in the average.

Alerts Fired​

How many alert firings occurred in the selected time window, at Low severity and above.

How it's calculated​

  • Sum of per-severity alertCount values from GET /api/v1/alerts/history for the chart snapshot window.
  • Only Low, Medium, High and Critical are counted. The history query builds its severity series from those four levels only, so Info and Best Practice firings never reach this number — they are dropped, not folded into Low. Alert Distribution does the opposite with the same two levels, so the two cards disagree by design.
  • Counts events in the window, including alerts that have since resolved — not the open backlog.
  • Instance filter applies. Hint text names the window label (for example Past 24 hours).

Reading it​

It is normal for Alerts Fired to be large while Active Alerts is zero: the estate fired and cleared inside the window. Compare with Alerts Activity (severity breakdown of the same history) and Open Alerts (what is still open). If a firing you expected is missing, check its severity — an Info or Best Practice alert is real but invisible here.

Alerts History​

Per-interval Active versus Resolved alert activity across the selected window.

How it's calculated​

  • Served by GET /api/v1/alerts/raised-resolved-history with the same from / to / bucketSize the page derives from the topbar time window.
  • Active: unmuted alerts whose firing window overlaps the bucket (a chronic alert can appear in many buckets).
  • Resolved: unmuted alerts whose resolved_at falls inside the bucket. Muted alerts are excluded.
  • Every bucket in the window is plotted, zeros included. This card has no per-bucket gap for time before monitoring began — a quiet bucket and a not-yet-monitored bucket both draw as zero.
  • When nothing at all was raised or resolved in the window, the card swaps to an empty state instead: Before monitoring started, naming the start date, if the whole window predates the earliest monitored instance, and No alerts fired in this window otherwise.

Reading it​

Read Active as "how much was on fire" and Resolved as "how much was closed". Rising Active with flat Resolved means the backlog is building. This card's visible title is Alerts History — do not confuse it with Alerts Activity (severity firings from /alerts/history), which is the card that breaks its line for buckets before monitoring started.

Alerts Activity​

Alerts fired per interval, stacked or lined by severity, for the selected window.

How it's calculated​

  • Served by GET /api/v1/alerts/history (same window snapshot as Alerts Fired and Resolution Time).
  • Each bucket counts firings by severity, including alerts that later resolved.
  • Only Low, Medium, High and Critical have a series. The history query's severity list stops at Low, so Info and Best Practice firings are excluded from this chart rather than folded into the Low series — they are absent, not merged.
  • Gaps appear for buckets before monitoringStartedAt when that timestamp is known: a bucket that predates monitoring renders as a break in the line rather than a measured zero.

Reading it​

Use this for "what severity drove the noise," not "what is open now." The visible title is Alerts Activity. Alerts History (raised/resolved) answers backlog motion; this card answers firing mix. A break in the line means "not monitored yet", while a plotted zero means "monitored, nothing fired".

Alert Distribution​

Share of currently open alerts by severity (Critical, High, Medium, Low).

How it's calculated​

  • Built from summary.bySeverity on the same un-windowed GET /api/v1/alerts/query call as Active Alerts / Critical.
  • Bars show percent of open alerts; a zero-count severity can still render as 0%.
  • There is no Info or Best Practice bar, but those alerts are not missing: the severity summary counts both levels inside Low. So Low here means "Low, Info and Best Practice", while the history charts drop those two levels entirely.
  • Instance filter applies; the time window does not. Subtitle: across open alerts.

Reading it​

This is a snapshot of the open queue's mix. It will disagree with Alerts Activity whenever recent firings have already cleared — and also because the two cards treat Info and Best Practice differently: folded into Low here, excluded there.

Resolution Time​

How long alerts raised in the selected window took to resolve.

How it's calculated​

  • From the same GET /api/v1/alerts/history payload as Avg. Resolution: average, median, and 90th-percentile resolution minutes (displayed as durations).
  • Every statistic is measured from an alert's creation to its resolved_at, over alerts raised inside the window that have since resolved — the closing time itself can fall outside the window.
  • No severity filter applies here, so Info and Best Practice alerts are included; muted alerts are excluded.
  • Empty state when nothing raised in the window has resolved yet. Instance filter and chart snapshot window apply.

Reading it​

Avg. Resolution is the mean alone; this card adds median and p90 so you can see skew. A calm median with a long p90 points at a few hard incidents. Remember that still-open alerts are missing from all three figures, so a window ending in the last few hours flatters the numbers.

Open Alerts​

The main alerts table for this page — open alerts whose last trigger falls in the selected window (grouped by template by default).

How it's calculated​

  • Flat: GET /api/v1/alerts/query with from / to on last_triggered_at and default status Active (New + Acknowledged).
  • Grouped: GET /api/v1/alerts/grouped for the same time and instance scope — one row per alert template code. Opening a group goes to /alerts/detail?code=….
  • Resolved and AutoResolved rows are hidden unless you widen the status filter. Muted rows stay hidden until Show muted is on. Charts still count all activity in the window.

Reading it​

A quiet list with busy Alerts History / Alerts Activity usually means alerts fired and cleared inside the window. Use Grouped mode to triage by template; use Flat when you need individual occurrences.