← Blog

Status page components: design names customers understand

Your status page is read by customers during stress — not by your SRE team. Labels like postgres-primary or k8s-deployment-api look precise internally and confusing externally.

StillOnline groups checks under components you name in the project dashboard. Visitors see those names on stillonline.tech/{locale}/s/{id} alongside probe history and incidents. This guide maps indie SaaS products to customer-facing component names.

Quick answer

Name StillOnline status page components after what customers use — Dashboard, API, Billing, Email — not servers or databases. Keep 3–5 components on indie SaaS; tie each to an HTTP check on Pro or combine signals in one /health on Free (one URL per project). When only one check exists, the page still shows overall status; split components when you add a second URL on Pro ($9/mo). See public status page guide.

Infra names vs product language

Internal name (avoid on public page)Customer-facing componentWhen to split
vercel-appWeb app or DashboardMarketing vs API on separate hosts
railway-workerBackground jobsJobs fail while web is green — workers guide
stripe-webhookPaymentsCheckout broken, API up — third-party status
auth0LoginIdP incident, not your deploy
sendgridEmail notificationsTransactional mail delayed

Google SRE recommends user-visible symptom language in customer comms — same rule for component titles.

Example maps by product shape

API-first B2B SaaS

ComponentMonitors
APIapi.product.com/health
Webhooksapi.product.com/webhooks/healthingestion guide
Dashboardapp.product.com/health (optional second check on Pro)

Indie app + billing

ComponentMonitors
AppMain product health URL
PaymentsManual incident when Stripe degrades — third-party
LoginAuth provider outage comms

Telegram bot / agent

ComponentMonitors
Bot APIPublic health or gateway URL — agent monitoring

Study how vendors name public components — e.g. Stripe Status uses Payments, Dashboard, and API — not database hostnames.

StillOnline setup

  1. App → project → name components in UI.
  2. Attach HTTP checks to the right component (Pro: up to 10 checks per project).
  3. Free: one check — use one component or overall status until you upgrade — pricing.
  4. Open incidents on the affected component, not “everything” — degraded vs outage.

Related guides

FAQ

Can I mirror Kubernetes service names on the public page?

Not recommended. Buyers do not know your cluster layout — use product language.

Does StillOnline auto-create components from checks?

You name components when configuring the project; align names before your first incident — incident template.

Free tier with one URL — multiple components?

Yes for manual incidents and labeling, but one HTTP check drives automated status until Pro adds more URLs.