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

In Components, use Add components to search monitors by name or target and select the services to include. Public names and section assignments are editable directly in each component card. Use the arrows or drag handles to change the order, including with a keyboard or on a phone. Removing a section moves its components into a neighboring section.

The builder supports up to 100 components and 30 sections per page. 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.

Embed service health on your website

Open Widgets in your workspace and choose one of six starting layouts: Status card for service details and history, Compact list for a smaller footprint, Status badge for an overall summary, Status banner for a slim strip of service health, Service grid for responsive tiles, or Uptime scorecard for prominent per-service availability. Choose a published public status page, then select and reorder up to 50 services. Widgets use the page's public component names and never need an API key or access to a visitor's account.

Use Appearance for the theme, accent, spacing, corners, text size, borders, and embed dimensions. Under Content, choose the title, 24-hour uptime, daily history, update time, branding, status-page link, and refresh interval. The badge and banner focus on current health; cards, lists, grids, and scorecards can show individual metrics. Scorecards display each service's 24-hour uptime separately, without averaging across services. Missing observations remain unavailable rather than showing 100% uptime. Switching templates applies its suggested size, spacing, and metrics while preserving your service selection, title, theme, and colors.

Check the live preview at desktop and mobile sizes, then choose HTML, React, Vue / Nuxt, Next.js, or Svelte. Each option includes placement instructions: HTML for a custom HTML block, JSX for React, a .vue component for Vue and Nuxt, a .tsx component for Next.js, or a .svelte component for Svelte and SvelteKit. The iframe adapts to its container up to your chosen maximum width. Set enough height for the selected services; longer content scrolls inside the widget.

Your latest design is saved in this browser for this account and workspace. To change an installed widget's design or selection, copy and paste the updated code. Service health refreshes automatically from the public page. Unpublishing the page or changing it to private makes its widgets unavailable on their next refresh. Newly added services are not automatically included in an existing widget.

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

New pages start as drafts. The Page preview renders the current configuration without saving or publishing changes, and follows the page's chosen appearance independently of the dashboard theme. Match visitor uses the dashboard's current theme for this preview. Use the desktop and mobile controls, or expand the preview for more room.

Open Publishing or select Review to check the component count, address, theme, and visibility. Validation messages link back to the settings that need attention. Save draft stores the configuration; Publish page or Publish changes makes it public. If you leave with unsaved edits, the builder offers to keep editing or discard them.

For an existing published page, Save as draft takes the page offline. There is no separate unpublished copy of a live page. Password and SSO access are not available; an existing private page must switch to public access before it can be published to visitors.

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.