Skip to main content
A public status page is a customer-facing view of your system’s health. It shows:
  • An overall banner — operational, degraded, partial outage, major outage, or maintenance.
  • A grid of components, grouped by label, each with its current status.
  • A list of active incidents with their full update timeline — latest expanded, older entries collapsed.
  • A section of scheduled maintenance windows — upcoming, in-progress, and recently-completed planned work.
  • A separate history view of resolved incidents over the past 90 days.
Pages are fully server-rendered HTML — fast, cached at the edge, and accessible without an account.
Public status page

A published status page at scaling.cloud/status/your-slug

​
Where pages live

By default, every published status page is reachable at:
The <slug> is a short, URL-safe identifier you choose in the admin UI. If you skip choosing one at signup, scaling.cloud generates a default slug for you that you can rename later. You can also attach a custom domain so the page is served at your own hostname (e.g., status.example.com). See Connect a custom domain.

​
How status is derived

Each component on a status page shows one of five statuses: The status for a component on the page is resolved in this order of precedence:
  1. Manual override set by an admin (e.g., to declare maintenance ahead of time).
  2. Open incident that tags the component — the worst severity wins.
  3. Active scheduled maintenance window that lists the component — sets it to maintenance.
  4. Default — operational if nothing above applies.
The overall banner takes the worst component status, ranked:
When the worst thing happening is maintenance, the banner reads “Under maintenance” — a distinct, expected (blue) signal rather than a “we have issues” warning. A real incident (degraded or worse) always outranks maintenance, so genuine problems are never masked. This applies to both an active maintenance window and a manual per-component maintenance override.

​
Active incidents and history

Active (unresolved) incidents that tag any of the page’s components are listed on the main page. Each incident shows its full update timeline in reverse chronological order: the latest update is rendered expanded; older updates are collapsed under a “Show all N updates” disclosure. Once resolved, an incident moves to the 90-day history view at /status/<slug>/history with the same timeline rendering.

​
What appears on the timeline

Each entry on the timeline is one of three kinds: The render rule is deliberately conservative: the public page is a customer-trust surface, so it favours visible removals over silent edits, and never collapses transition history.

​
Automated entries

Some entries are posted by the platform rather than a person — an auto-resolution when an ingested alert clears, for example. A message or transition entry whose origin is system carries an Automated badge instead of any human attribution, so customers see that the platform — not a named engineer — took the action.

​
Publishing requires component overlap

Responders who try to publish a public update on an incident whose affected components don’t overlap with any published Status Page’s selected components get a NO_PUBLIC_SURFACE error. This prevents publishing into the void. If your team hits this rejection often, either:
  • Add the missing components to the relevant Status Page (Settings → Status Page → Components), or
  • Tag the incident with one of the components your Status Page already shows.

​
JSON API

The same data that renders the page is available as JSON for embedding in your own tools or status banners:
Neither endpoint requires authentication. The live snapshot includes a maintenances array of scheduled maintenance windows — see Scheduled maintenance — In the JSON feed for its shape.
The JSON endpoint is cached for 30 seconds at the edge. If you embed it in a high-traffic surface (a footer banner, a help center widget), the cache is sized for that traffic — you do not need to add your own.

​
Configuring a status page

Status pages are configured in Settings → Status Page in the dashboard:
  • Slug — the URL-safe identifier used in /status/<slug>.
  • Selected components — which components from your catalog appear on the page. This is also the set that gates public incident updates: an incident’s affected components must overlap this set for a responder to publish a customer-visible update on it.
  • Group labels — components are grouped by their groupLabel (see Components).
  • Manual overrides — set a component to maintenance or degraded ahead of time.
  • Scheduled maintenance — announce planned work as a titled, time-boxed notice spanning multiple components. See Scheduled maintenance.
  • Published — toggle to expose the page publicly. While unpublished, the page returns a 404 — and any attempt to publish an incident update against components only on this page is rejected with NO_PUBLIC_SURFACE.
Status page settings

Status page settings in the admin dashboard

For a step-by-step walkthrough, see Publish a status page.