Engineers love mapping every deployable to a status row. Customers love knowing whether Login, API, and Billing work. Those goals conflict.
A useful upper bound
If you cannot explain a component in one plain sentence to a support ticket, cut it. For an early SaaS, three to eight public components is the sweet spot. Past ~12, people stop parsing the page.
Name for buyers
Good: App, API, Dashboard, Authentication, Payments, Status page itself.
Bad: invoice-worker-v3, eu-west-redis, feature-flags-sidecar.
Internal names can live on an internal dashboard. Public pages get product language.
Aggregation
Many services can back one component. If any critical dependency in "Checkout" is down, Checkout is down or degraded. Customers do not need the dependency graph during an outage.
Automation pitfall
One flaky monitor per microservice → eternal yellow Christmas tree. Fewer components, wired to trustworthy checks, beat a faithful map of chaos.
Review quarterly
Delete components nobody mentions in tickets. Merge rows that always fail together. Add a row only when support keeps saying "which part?"
The status page is a communication surface. Treat component count like bullet points on a slide: enough structure to be clear, not so much that nobody reads.