Model status page components around what customers can do, such as sign in, call the API, receive webhooks or view reports, not around your internal microservices. Aim for roughly 5 to 12 components. Fewer hides real partial outages. More teaches customers your architecture and makes every update harder to write.
The two common mistakes
One big light. Everything is "operational" until the whole product is down. Customers who cannot log in see green and open tickets, which defeats the purpose.
Internal names. "auth-svc-eu2 degraded" means nothing to a customer. They cannot tell whether it affects them, so they ask support.
Start from customer actions
List what a customer does in a normal day. Typical entries for a SaaS product:
- Sign in and single sign on
- Web application
- Public API
- Webhooks and outbound notifications
- Scheduled jobs and reports
- Integrations with third party services
- Billing and invoices
- Support portal
Then map each action to the internal services it depends on. Several services can sit behind one component. One service can feed many components.
Handle regions and tenants
If you run separate regions, add regions as sub-components of the ones that differ, not as a copy of the whole list. If only some tenants are affected, say so in the incident text rather than inventing a component per tenant.
Decide what counts as degraded versus down
Write the rule down before an incident:
- Degraded: works for most users but slower, or a minority of requests fail.
- Partial outage: a feature or region is unusable for a clear group.
- Major outage: the component is unusable for most users.
Use your own measured signals, such as error rate or latency over a window, so the decision is not an argument at 3 a.m.
Third party dependencies
If a cloud provider or payment processor failure breaks your component, mark your own component, and say in the text that an upstream provider is involved. Customers care that their action fails, not whose fault it is.
Review twice a year
New features add components nobody remembers to list. Add a calendar reminder and check the list against the product menu.
Quick check
Should security incidents appear on the status page?
Availability effects should. Confidentiality incidents usually need a separate customer notice, covered in your incident communication plan.
Can we hide minor blips?
You can set a threshold, but write it down and apply it the same way every time.
Last reviewed: 19 October 2026.
