# How to Name Status-Page Components
Component names should match customer workflows, not your microservice map. Three to seven components stay readable on mobile and during stress.
Author: fajita-editorial
Published: 2026-07-17
Updated: 2026-07-17
Last reviewed: 2026-07-17
Version: 1
Canonical: https://fajita.io/blog/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.

| Internal name | Customer-facing name |
| --- | --- |
| auth-gateway | Login and signup |
| report-export-queue | CSV exports |
| stripe-webhook-ingest | Billing and subscriptions |

## 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.
Original contribution: Customer-language naming table mapping internal services to status page labels.