What a status page is really for
A status page is not a dashboard. Your dashboard is for you and it is dense on purpose. A status page is for people who are not on your team, are already frustrated, and want one question answered: is it you, or is it me?
That means the design goal is not completeness. It is an unambiguous answer within two seconds of the page loading, followed by a plain-language explanation for anyone who scrolls.
Automatic signal, manual narrative
The uptime bars and current component states are generated automatically from probe data, so the factual layer of the page is always accurate without anyone touching it.
The narrative layer is deliberately manual. Automated systems know that a check is failing; they do not know that the cause was a bad migration and that recovery will take forty minutes. That context is what your users actually want, and it has to be written by a human.
- InvestigatingYou know something is wrong and are actively looking. Post this fast — speed beats detail.
- IdentifiedYou know the cause. Say what is affected and what is not.
- MonitoringA fix is deployed and you are watching recovery. Do not resolve prematurely.
- ResolvedConfirmed healthy, with a short summary and a postmortem commitment if it was serious.
Independence from your infrastructure
A status page hosted inside the infrastructure it reports on is useless at exactly the moment it matters. SutramX serves status pages from separate infrastructure, so your page stays up when your origin does not.
Specifications
| Custom domain | Yes, with managed TLS |
|---|---|
| Branding | Logo, colours, and page copy |
| Uptime history | Rolling daily bars from real probe results |
| Incident updates | Investigating, identified, monitoring, resolved |
| Hosting | Independent of your monitored infrastructure |