Running the status page
Components, incidents, subscribers and the feed — on a deploy that survives what it reports on.
The status app is a separate deploy with its own database. That is the whole point of it, and it is worth not undoing for convenience.
What it holds
- Component groups and components — the systems you advertise a status for.
- Incidents — customer-facing, and deliberately separate from your internal ones. What you tell the world is an editorial decision, not a copy of your alert stream.
- Updates — the timeline on an incident.
- Maintenance — scheduled windows, announced in advance.
- Subscribers — email and webhook targets for people who would rather be told than check.
How it learns anything
on-call pushes HMAC-signed events to it. The status app applies them to its own store and regenerates the public page as a snapshot. It never reads on-call’s database, so on-call being down does not stop the page rendering.
What you can build against
GET /— the public page, snapshot-servedGET /api/v1/summary— current state as JSONGET /feed.rss— the same thing as a feed
One rule worth keeping
Do not put the status page on the infrastructure it reports on. It is the one page that has to be up on your worst day.
Was this helpful?
Still stuck? Contact support.