Reliability
Alerts, SLOs, and incidents used to be three disconnected screens you had to correlate yourself. Reliability puts them behind one URL — a posture strip up top, three tabs below — so an SLO shows you the alert watching it, and an incident links back to the alert it was filed from.
What you see
Reliability posture
A strip of three stat blocks above the tabs: Active alerts, SLOs at risk, and Open incidents, each colored teal when clear and amber/red when not. Clicking a block switches to that block’s tab.
Active-alert and open-incident counts come from a single GET /reliability/posture call; SLOs at
risk is derived client-side from the SLOs list, counting an SLO only when it has a real
value (not “insufficient data”) and its status is not met.
Alerts
A table of alert rules — agent, type, threshold, last fired, an Investigator status badge, an active toggle, and delete — plus a Create Alert dialog.
Nine alert types are available: failure rate, inactivity, cost threshold, latency threshold, eval score, cost per run, daily spend, SLO burn rate, and metric anomaly — the create form’s fields (threshold label, extra config) change per type.
Two more types, budget threshold and budget forecast, are tied to a
budget rather than an agent. They are evaluated hourly instead
of on the 5-minute sweep, and are created through the API (POST /api/v1/alerts with a
budget_id) because the Create Alert dialog does not offer them yet.
- Budget threshold fires when a budget’s spend reaches a percentage of its amount — 50%, 80% and 100% by default. Each threshold fires once per period; editing the amount or toggling the budget does not re-arm one that already fired.
- Budget forecast fires at most once per period, when a budget becomes projected over. It does not fire before the forecast is ready or once the budget is already over.
These alerts, and a daily spend alert scoped to the whole org, have no owning agent. They go to every org member who has notifications turned on for that severity and channel; if no member does, Morse emails the org owner.
Clicking an agent name opens that alert’s detail page.
SLOs
A card grid, one card per SLO, each showing the target, the current value, an error-budget progress bar, a met/breached icon, and — if a burn-rate alert is attached to it — a link to that alert.
Target types are success rate, latency P95/P99, availability, cost per run, or a custom metric. The window is a preset dropdown — 7, 14, 30, or 90 days — not free text.
An Evaluate button re-runs all SLO evaluations on demand, and New SLO opens the create form, which can define a brand-new custom metric inline without leaving the flow.
Incidents
A filterable (all / open / investigating / resolved) list of incident rows, each with a severity badge, a status badge, and a relative timestamp; a New Incident button opens an inline create form.
Clicking a row opens that incident’s timeline.
How to use it
- Scan the posture strip first — it tells you which of the three tabs, if any, needs attention.
- Switch tabs to work the specific surface: create or toggle an alert, define an SLO (and its custom metric, if needed), or file and filter incidents.
- Follow a burn-rate-alert link from an SLO card, or an alert link from an incident’s timeline entry, to move between the three without losing context.
- Each tab’s empty state cross-links to the other two, so picking the wrong tab for what you’re trying to do isn’t a dead end.
Burn rate is Google’s SRE-workbook single-window formula — current_error_rate / error_budget —
evaluated once per SLO per check, not the dual-window (fast+slow) technique.
Before you have data
- No alerts configured: “No alerts configured”, with a prompt pointing to SLOs and Incidents.
- No SLOs configured: “No SLOs configured yet. Create one to start tracking reliability.”
- No incidents recorded: “No incidents recorded” (or “No incidents match this filter” when a status filter is active), with a prompt pointing to Alerts and SLOs.
To get your first alert or SLO here, follow the quickstart.