How to Name Status-Page Components

Status page components tell customers which slice of your product is impaired. Names that mirror internal codenames force customers to translate during an outage. Names that mirror how people describe your product let them self-serve in seconds.

Use customer language

Prefer labels customers already use in support tickets: Login, Dashboard, Billing, API, notifications. Avoid names like svc-payments-worker unless your audience is exclusively developers integrating with that service.

Keep the list short

• Three to seven components cover most SaaS products
• Split only when failures can be isolated in practice
• Merge components that always fail together
• Add a catch-all only if it genuinely helps, not as a junk drawer

Order by customer impact

1. List revenue or login paths first
2. Group secondary features below
3. Put internal or admin-only systems on a separate internal page if needed

Review names after real incidents

If support still asks which component is down, your names are too vague or too granular. Update labels when you rename product areas. A status page that matches marketing language ages better than one copied from an architecture diagram.

Run a fifteen minute review with someone from support after your first public incident. Ask which component names confused customers. Rename before the next outage rather than defending jargon because engineering prefers it.

Examples that work on small SaaS products

• Login and signup instead of auth-service
• Billing and invoices instead of payments-worker
• File uploads instead of object-storage-gateway
• Email delivery instead of notification-queue

Each label should answer which customer workflow is affected. If a friend who uses your product would not recognize the name, pick a simpler one.