Status endpoints
Snapshots, summaries, monitors and uptime, with full payload shapes.
Use /status/summary for a compact dashboard response or /status for the
full page snapshot. Monitor routes let you read one service and its uptime.
These read endpoints are public and use the same snapshot cache as the page.
GET /status
The full public snapshot contains the monitors, daily history, incidents and maintenance shown on the page.
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
Use this for a load-balancer probe, not service health. It only confirms that
the API is serving; it doesn't query the database or check your monitors.
Use /status/summary to read the actual status.
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.