Feeds and snapshots

Every published status page serves two machine-readable surfaces beside the HTML a reader opens. This page is the contract for both.

snapshot.json

snapshot.json is the curated snapshot the page itself is built from. The route makes one database call and no other — the same published-gated read the HTML page makes — and hands back what it got. Nothing is composed for the feed, so nothing reaches it from outside the curated snapshot the page itself is built from.

RSS

The feed is rendered from that same snapshot and from nothing else. The renderer is handed the snapshot and the feed’s own address, so an update the page does not show is an update the feed does not carry.

On a custom domain

On a verified custom domain the same surfaces sit at the root, and both conditions are checked on each of them. /snapshot.json, /rss and /subscribe are served on the domain itself, with no <slug> segment in front of them — and each of them requires the domain to be verified and the page behind it to be published. The read side and the subscribe side test both conditions for themselves, so a domain that stops being verified stops serving and stops accepting subscriptions in the same moment.

When there is nothing to serve

Both surfaces answer 404, and they answer it to three different questions. A slug no page holds, a page that exists but is not published, and a custom domain that is not verified are one answer apiece — the same 404 with the same body — on snapshot.json and on the feed alike. Nothing in the response tells them apart, so neither surface can be used to find out whether a status page exists.