What Components to List on Your Status Page (And What to Leave Off)

When you set up a status page for the first time, the first real decision you make isn't design or domain or who gets notified. It's this: what components should I list?

It sounds trivial. It's not. The components you choose shape everything downstream — what customers see during an incident, what you're on the hook to update, what "operational" even means for your product. Get it wrong and your page is either overwhelming, misleading, or useless.

The mistake almost every first-time status page owner makes is obvious in hindsight: they list their infrastructure. Database, API server, queue worker, cache layer, CDN. It's the first list that comes to mind because it's the one their architecture diagram already has.

That's the wrong list.

Think about your customers, not your stack

Your status page has one job: tell your customers whether the things they care about are working. Your customers do not care about your Postgres replica. They care about whether they can log in, whether they can upload a file, whether their dashboard loads, whether the API they're building against is returning valid responses.

When you list "Database" as a component, you're asking your customer to translate from something they understand (I can't log in) to something they don't (is the database the reason?). That translation fails every time. They see "Database: Operational" and they don't believe you, because from where they're sitting, nothing is operational.

The fix is to list components as user-facing capabilities, not as infrastructure layers. Here's the shift:

Not "API Server" — use "REST API" or "Webhooks"
Not "Database" — use "Login & Authentication" or "Dashboard Data"
Not "Redis Cache" — either roll it into the capability it supports, or don't list it
Not "Background Workers" — use the thing the worker does, like "File Uploads" or "Email Delivery"
Not "Load Balancer" — nobody hits a load balancer on purpose

The test is simple. If a customer couldn't, on their own, figure out what it means when this component goes red, don't list it.

Good components describe outcomes, not causes

Think about what your customer was trying to do when things broke. Were they logging in? That's a component. Were they uploading an invoice? That's a component. Were they checking yesterday's analytics? That's a component.

Components that describe outcomes have a nice property: they map cleanly onto your support inbox. When someone emails you "I can't upload files," the first thing you want to do is check the "File Uploads" component on your own status page. If it's green, maybe it's a user-specific issue. If it's red, you already know. Your support team can triage incidents using the status page the same way your customers do.

Infrastructure-named components don't give you that. "Worker Queue: Degraded" doesn't help your support team answer "why can't I upload files" any faster.

The right number of components

For most small teams, the right number is between four and eight.

Fewer than four and you're probably hiding things in an umbrella component that's going to go red during partial outages and confuse everyone. "Platform" or "Core Services" or anything that vague is a smell. If half your product is broken and the other half works, customers need to see that — one "Platform: Degraded" bar doesn't tell them which half.

More than eight and you're probably back in infrastructure territory. If you've listed ten components and half of them sound like AWS services, you're not thinking about customers anymore. Nine out of ten customers don't know what any of those mean, and the tenth is already deep enough in the weeds that they'll check your logs anyway.

There are exceptions. If your product is a multi-service platform where each service is independently sold — the way larger platforms have an API product, a dashboard product, a mobile app, and a partner portal — then eight to fifteen is fine because each component really is a distinct product. But the threshold is "distinct thing a customer bought," not "distinct thing the engineering team deploys."

Components worth including most of the time

For a typical small SaaS, the useful components usually come down to some subset of these:

Dashboard / Web Application — the browser-based product itself
Login & Authentication — because when this breaks, everything else feels broken
REST API / GraphQL API — if you offer programmatic access, split this out
Webhooks — if you send them, because webhooks failing is silent from the receiver's side until something downstream catches fire
Email Delivery / Notifications — outbound email, usually the quietest outage
File Uploads / Storage — if uploads are meaningful to your product
Billing / Checkout — often the most sensitive one because downtime here means lost revenue for you and confusion for customers
Search — if search is a meaningful part of the experience and can fail independently of the rest

Pick the four to eight of these that actually matter for your product. Skip the rest.

Components worth leaving off most of the time

Some things look like status page material but create more confusion than value.

Your internal admin tools. If your customer-facing product is up but your internal support dashboard is down, that's an internal incident, not a customer incident. Don't mix them. Use a separate internal status page if you need one.

Third-party dependencies you don't control. Listing "Stripe" or "AWS S3" on your page is tempting because it lets you pass the buck during outages. Resist. Your customers don't care whose fault it is — they care whether your product works. If a third-party outage breaks a capability, mark the capability as degraded and mention the upstream cause in the incident write-up. Don't make the customer learn your vendor list.

Staging, preview, or non-production environments. Nobody outside your team needs to see these.

Anything you can't actually monitor. If you don't have a signal that tells you this component is broken, don't list it. An unmonitored component is just something else for you to forget to update during an incident. Better to have four components you actively watch than twelve you manually guess at.

A few edge cases worth thinking about

What if one capability depends on another? Like, "File Uploads" depends on authentication working, which depends on the database. This is common. The right answer is to only mark the most specific affected component, not everything downstream. If auth is broken, mark "Login & Authentication" as down and leave File Uploads alone — customers will figure out the implication, and if you mark five things down at once for a single root cause you look like you're having five incidents.

What if you're not sure whether something belongs? Default to leaving it off. You can always add it later. Removing a component after launch is worse, because any customer who was subscribed to notifications for it is about to get an "unsubscribed" email that makes your product look unstable.

What if your customers already know your architecture? Like, developer-tool customers who do know what a queue worker is. Fine — but still prefer capability-named components. Even a developer would rather see "Webhook Delivery: Degraded" than "RabbitMQ Consumer: Degraded." The developer will know what you mean either way; the less-technical coworker they're pointing at the page won't.

The test

Once you've picked your components, do this: imagine three different things go wrong at the same time, and a customer lands on your page. Can they tell what's affecting them and what isn't, in under ten seconds, without knowing anything about how you built your product?

If yes, your component list is probably right. If they have to squint, translate, or guess, rename things until they don't.

PageCalm is a status page tool built for solo founders and small teams, with AI-written incident updates and a clean public page your customers will actually understand. Start free