Publish a useful status page

Design for customer questions

A status page should answer three questions quickly:

1. Is the service operating normally now?
2. Which customer capability is affected?
3. What has changed since the last update?

Customers do not need your internal hostname, probe configuration, organization ID, or private investigation notes. Translate monitors into product language such as Dashboard, Public API, Authentication, Billing, and Integrations.

Plan sections and components

Use sections to create an information hierarchy that remains readable when the page contains dozens of components. A typical SaaS structure is:

• Core platform: dashboard, authentication, API;
• Data processing: ingestion, background jobs, exports;
• Integrations: webhooks, email delivery, third-party providers;
• Regions: only when customers understand and need regional status.

Each component can use a public display name that differs from its internal monitor name. Order the most important customer paths first. Avoid duplicating one monitor across many components unless each placement has a clear communication purpose.

Create the page identity

From Status pages, create a new page and configure:

1. Name and slug. The slug becomes part of the public route, so choose a stable, readable value.
2. Description. Explain what the page covers and where customers should go for account-specific support.
3. Appearance. Select light, dark, or system mode, an accent color, logo, and optional platform branding.
4. Links. Add support, documentation, or primary product links that help during an incident.
5. Visible metrics. Choose whether to show uptime, history, history length, regions, SSL information, and last-checked time.

Visible metrics should help interpretation. Showing every available datum can overwhelm the page and accidentally expose implementation detail.

Organize components

Create sections, add monitor-backed components, set their public display names, and drag them into the desired order. Preview the result at desktop and mobile sizes.

For every component, verify:

• the display name is customer-facing;
• the section reflects the way customers understand the product;
• the monitor actually represents that capability;
• uptime history uses the intended range;
• no target URL or organization metadata is visible.

Large pages benefit from short section names and fewer than roughly ten components per section. When a section grows beyond that, split it by product area or customer workflow.

Understand automatic incident state

Confirmed incidents connected to page components appear automatically. The current incident banner summarizes active impact, while incident updates create a chronological public timeline.

Internal incident evidence and public updates serve different audiences. The incident timeline may contain probe details, request evidence, delivery records, and internal notes. Public updates should say:

• what customers are experiencing;
• which components are affected;
• what the team is doing;
• when the next update is expected.

Use a custom public incident title when the internal monitor name is too technical. Component impact should be scoped accurately rather than marking the entire platform unavailable.

Publish maintenance

Maintenance windows appear on a public page when the window is published and its affected monitors belong to page components. Include a clear title, start and end time, description, and component scope.

Communicate times with an explicit timezone in prose, even if the interface formats dates for the viewer. If the work finishes early or runs long, update the window so customers do not have to infer current state.

Maintenance is visually neutral and distinct from unexpected downtime. Planned work may degrade a component, but it should not be represented as an incident unless unplanned customer impact occurs outside the maintenance contract.

Use draft and preview safely

Keep a new page in draft while building its information architecture. The editor preview renders the current configuration without making those changes public.

Before publishing:

1. Test light and dark appearance independently of the dashboard’s own theme.
2. Verify the component order and mobile wrapping.
3. Confirm history, uptime, regions, SSL, and last-checked visibility.
4. Check active incident and upcoming maintenance presentation.
5. Open the public response without a signed-in session and inspect it for private targets or organization data.
6. Ask a teammate unfamiliar with the internal architecture to explain the page back to you.

Draft changes should remain safely previewable. Publishing is the explicit action that updates what visitors see.

Prepare subscriber notifications

The public subscriber interface supports email verification and notification preferences. Verification protects recipients and confirms consent before updates are delivered.

Subscribers should be able to choose the kinds of events they receive. Keep subscription language clear about incident and maintenance notifications, and do not imply delivery channels that are not enabled.

Test the full path with a non-team email address:

• submit a subscription;
• receive and complete verification;
• confirm preferences are saved;
• publish a controlled update;
• verify the resulting delivery and unsubscribe behavior.

Write useful incident updates

Use a predictable rhythm:

1. Investigating: describe the observable customer impact and affected components.
2. Identified: explain the broad cause when confirmed, without speculation or unsafe detail.
3. Monitoring: state what changed and what evidence will prove recovery.
4. Resolved: give the impact window and confirm normal operation.

Avoid repeating “we are investigating” without new information. If there is no material change, say what is being checked and give the next update time.

Operate the page over time

Review the page quarterly and after material architecture changes. Remove obsolete components, rename internal language, verify support links, test subscriptions, and compare public incidents with the internal incident record.

The page should remain useful during the most stressful event your team handles. If responders must manually reconstruct component mappings during an outage, improve the structure before the next one.