Choosing status page components is mostly a communication problem, not an architecture problem. Good components help customers understand what is affected. Bad components expose internal system names that customers cannot map to their own experience.
If you want the product side, see Create a public status page and Incident management. This guide focuses on component design.
What a component should do
A good component should answer one question fast:
If this component is degraded, will a customer know whether they are affected?
If the answer is no, the component definition needs work.
Start with customer-visible surfaces
Good starting components often include:
- Website
- API
- Authentication
- Webhooks
- Email delivery
- Mobile app
These map to customer behavior better than internal infrastructure names.
Avoid infrastructure-first naming
Weak component names:
- primary database
- worker cluster b
- async pipeline v2
- edge gateway shard 3
Those may matter internally, but they do not help customers interpret impact.
How many components is too many
Most teams should start smaller than they think.
| Team size or complexity | Good starting range |
|---|---|
| Small SaaS | 4 to 8 components |
| API-heavy platform | 6 to 12 components |
| Multi-product platform | More, but grouped clearly |
Too many components create maintenance overhead and make the page harder to scan.
Group by user experience, not org chart
A useful component model is usually based on workflows customers care about:
- can I log in?
- can I call the API?
- are webhooks delivering?
- are emails being sent?
That is a better structure than copying internal service ownership boundaries directly.
Component naming also works better when the rest of the page feels consistent and recognizable. For that, see Custom branding for status pages.
Practical rule
If support would have to translate a component name for customers during an incident, rename it before publishing.
FAQ
Should every internal service become a public component?
No. Only publish components customers can understand and that meaningfully map to user-visible impact.
How many components should a status page start with?
Usually 4 to 10 customer-facing components is enough for a first version, depending on product complexity.
Can components change over time?
Yes. Teams should refine components as the product changes or as incident communication reveals where the current model causes confusion.