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.
Based on operational experience at StatusPage.me, teams most often get component design wrong in the same two ways: they publish too many components mirroring internal service boundaries, or they publish a single catch-all component that tells customers nothing useful about the scope of an incident. Industry surveys find that status page visitors primarily want to know whether the part of the product they use right now is affected — not the full internal dependency graph.
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.
How StatusPage.me handles this
Create a public status page on StatusPage.me lets you define components individually and group related ones under a parent so customers can scan impact at a glance without wading through a long flat list. You can rename or reorganize components at any time without affecting incident history, so refining your model after launch has no downside. During an active incident, you update individual component statuses rather than marking the whole page degraded, which lets customers self-triage quickly. Components also appear in subscriber notification emails, so a well-named component list directly improves how clear your alert emails are.
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.
