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/s/demo 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 component | When to split |
|---|---|---|
vercel-app | Web app or Dashboard | Marketing vs API on separate hosts |
railway-worker | Background jobs | Jobs fail while web is green — workers guide |
stripe-webhook | Payments | Checkout broken, API up — third-party status |
auth0 | Login | IdP incident, not your deploy |
sendgrid | Email notifications | Transactional 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
| Component | Monitors |
|---|---|
| API | api.product.com/health |
| Webhooks | api.product.com/webhooks/health — ingestion guide |
| Dashboard | app.product.com/health (optional second check on Pro) |
Indie app + billing
| Component | Monitors |
|---|---|
| App | Main product health URL |
| Payments | Manual incident when Stripe degrades — third-party |
| Login | Auth provider outage comms |
Telegram bot / agent
| Component | Monitors |
|---|---|
| Bot API | Public 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
- App → project → name components in UI.
- Attach HTTP checks to the right component (Pro: up to 10 checks per project).
- Free: one check — use one component or overall status until you upgrade — pricing.
- Open incidents on the affected component, not “everything” — degraded vs outage.
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.
Further reading
Public status page for SaaS and API
Ship a public status page so customers see uptime, history, and incidents. Works for SaaS, APIs, Telegram bots, and self-hosted agents — free on StillOnline.
B2B SaaS Status Page for Customer Trust — StillOnline Guide
Why B2B buyers ask for a status page link, how to add it to contracts and security reviews, and set up StillOnline checks with Telegram bot alerts.
Degraded vs outage on your status page
When to use Degraded, partial outage, or major outage on StillOnline—so one bug does not look like total downtime.
Third-party status: Stripe, Auth0, SendGrid on your page
When Stripe, Auth0, or SendGrid is down but your API is up: how to label degraded third-party components on a StillOnline status page without false ownership.