Status endpoints
Snapshots, summaries, monitors and uptime, with full payload shapes.
All four are public and unauthenticated. They read the same cached snapshot, so a page render and an API call can never disagree about the current state.
GET /status
The full public snapshot — everything the page renders.
Maintenance wins, then a critical incident, then any incident, then the monitors themselves.
Exactly displayDays entries, oldest first. status is up, down,
degraded or empty.
Hourly averages over the last 24 hours while raw rows exist, otherwise daily averages over 7 days. Empty buckets are omitted.
Whether any public monitor is configured, and whether any check has landed. Themes use them for the onboarding state.
Private monitors never appear here.
GET /status/summary
A deliberately small payload for embeds, uptime widgets and dashboards — no day grid, no latency series.
activeIncidents and scheduledMaintenances are counts here, not arrays.
GET /monitors
The monitors array from the snapshot, unchanged.
GET /monitors/:name
One monitor, or 404 { "error": "Monitor not found." }. Percent-encode names
with spaces.
GET /monitors/:name/uptime
Just the numbers, for an SLA report or a dashboard tile.
window is uptime across the configured display window, which is not always
90 days — displayDays tells you what it covers. A null means no checks
exist for that period, which is different from 0.
GET /healthz
It answers whether the status API itself is serving — it does not read the
database and does not reflect monitor state. Use it for a load-balancer
probe; use /status/summary for actual service health.
Caching
Snapshot reads are served from the in-process cache for
cache.snapshotTtlMs (default 30 s). Check runs and admin mutations
invalidate it. Responses carry no Cache-Control, so add your own edge
caching if you need it — badges are the exception and set
public, max-age=60 themselves.