Skip to main content

Public Status Pages

The public status page is the customer-facing surface of StatiBeat.

Public status page in the live demo

tip

The public page is designed to answer two questions quickly: what is affected right now, and what changed recently.

What the page shows​

Based on the current frontend implementation, the status page can render:

  • an overall current status area
  • active incidents
  • active and upcoming maintenance
  • a service or component hierarchy
  • previous activity

The homepage order and visibility of sections are configurable through site settings. The frontend normalizes homepage_section_order and homepage_hidden_sections when rendering the page.

note

The current page supports grouping and filtering in the impact summary area, which makes hierarchy quality especially important for customer-facing clarity.

Routing and access​

The public routes support both:

  • current-host routing
  • explicit /status/<url-prefix> routing

If the page is private, visitors are gated before page data loads. The current application supports:

  • shared viewer password
  • viewer SSO
  • shared password or viewer SSO

Those private-page rules are resolved by the same frontend route layer that loads the public page.

Detail routes​

Users can navigate from the homepage into:

  • service detail pages
  • incident detail pages
  • maintenance detail pages

Resolved incident detail pages can also render a published Post-Incident Report inline when a page operator has attached one.

Leaf service detail pages can currently show:

  • Uptime Overview
  • Status by Day
  • an optional Metrics tab when a page admin has configured a public Beat for that service

The first public metrics release keeps the viewer choices fixed to Day, Week, and Month, with server-selected bucket sizes and sanitized chart cards rather than raw synthetic evidence.

Page presentation settings​

The admin customization page and the Terraform statuspage_site_settings resource both expose controls for incident-card presentation, including:

  • primary message mode
  • whether affected summary appears
  • whether started and last-updated timestamps appear
  • whether impact text appears on collapsed cards
  • whether a view details link appears

Hosted embeds​

The current implementation also supports hosted embeddable surfaces for external properties:

  • a cache-friendly SVG badge
  • a branded iframe widget

Those surfaces are configured from the Embeds tab in page customization and rendered from stable hosted endpoints under the page-scoped public API.

The first embed release is intentionally lightweight:

  • badge enable or disable
  • badge label
  • widget enable or disable
  • branding inherited from the page title, logo, and brand colors
note

Hosted embeds inherit the same public-page visibility rules as the rest of the page. On private pages, viewer access still applies, which makes embeds most practical on public pages.

Admin analytics for public surfaces​

Page admins can now review bounded analytics for the public page and its hosted embeds without exposing raw visitor logs.

The current analytics workspace focuses on:

  • page views and estimated unique visitors
  • hosted badge and widget impressions
  • subscriber growth and deliverability mix
  • incident and maintenance activity
  • notification delivery outcomes by channel

Those analytics are available in the admin UI, the page-scoped admin API, Hosted MCP, and the page MCP server. They stay read-only and operational rather than becoming public-page content or Terraform-managed configuration.

Default component behavior​

The customization UI also supports:

  • showing a component by default
  • selecting a default component item

Those fields are backed by the admin settings payload used in application/frontend/src/pages/admin/Customization.jsx.

Incident history cues​

Resolved-incident cards and history views can show a Post-Incident Report indicator when a published report is available.

That helps readers distinguish between:

  • an incident that is only resolved
  • an incident that also has a published follow-up explanation
What this means operationally

You can keep the same underlying data model while changing how much history or structure appears on the public homepage. That is useful if you want different communication styles at different stages of the product.