Status pages
A page your own customers can read, showing what is up and what is not, hosted by us so that it answers when your infrastructure does not.
Building one
Create the page, then add components to it. A component is a monitor you have chosen to publish, under a name your customers will understand — “Checkout” rather than prod-api-lb-01. Group them into sections if there are enough to need it.
Adding a component is the act of publishing that monitor. Its state, its history and its incidents become visible to anybody with the link. Nothing else on the monitor is exposed — not the URL, not the configuration, not where the check ran from — but the fact that it is up or down becomes public. That is the point, and it is worth being deliberate about which monitors you add.
You can only add monitors from the same workspace as the page. In an agency account that is what stops one client’s monitor appearing on another client’s page.
Where it lives
Every page gets an address on our domain immediately. On Starter and above you can point your own domain at it instead — status.yourcompany.com — and we take care of the certificate.
On Pro and above the page can be white-labelled: your logo and colours, and no mention of us.
Incidents on the page
An incident opened by monitoring appears automatically. You can also post one by hand for something we cannot see — a degraded third party, a planned migration — and update it as it develops. Updates are timestamped and kept, so the page is a record afterwards rather than only a snapshot during.
A scheduled maintenance window is published on the page — its title, its description and when it is next due — as long as “show on status pages” is on, and it appears in the page’s feeds too. Subscribers can be told when it starts and when it is over. It holds back alerts while it is open, but it does not rewrite the uptime figure: unless you also turn off “keep checking”, the checks run as usual and count as usual.
Subscribers
Visitors can subscribe to be emailed when something changes. They confirm first, and every message carries a way out that works without signing in — the recipient of a status update is somebody else’s customer, and asking them to create an account in order to stop unsolicited mail is how a page earns a spam complaint.
Those addresses are people’s personal data that you have collected and we hold for you. They are yours: export or delete them whenever you like.
Private pages
Set a password and the page asks for it before showing anything. Useful for an internal page or one shared with a single customer under an agreement.
The unlock is remembered in a cookie for that one page, so unlocking one does not unlock another, and a visitor who has unlocked a page is always served the live version rather than a cached copy.
What we deliberately do not show
Nowhere on a status page do we name where a check ran from. Not on the page, not in an incident, not in the API. Where a check runs is ours to decide and ours to change — probes move between hosts and locations — so a region code in front of your customers is a claim about our infrastructure that goes stale without anyone noticing, and it is not something they could act on.
Feeds
Every public page publishes its incidents as a feed, in both of the formats readers understand: /feed.xml for RSS and /atom.xml for Atom, each sitting beside the page’s own address. Both are linked from the page, so most readers find them from the page URL alone.
A feed is how somebody follows you without handing over an email address. It carries exactly what the page carries — the incidents of the last thirty days, the updates you marked public, and the maintenance windows you chose to publish — and nothing else: no internal note, no postmortem, and nothing about where a check ran from.
A password-protected or restricted page serves no feed. A feed reader cannot be asked for a password, so a feed there would be a way around the gate rather than a feature.
Speed and availability
Status pages are cached at the edge and served from a copy that survives our own origin going down. That is the whole reason to host a status page somewhere other than the thing it reports on: a page that is unreachable during exactly the outage somebody follows it during has failed at its only job.