A public status page is a customer-facing view of your system’s health. It shows:Documentation Index
Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt
Use this file to discover all available pages before exploring further.
- 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 separate history view of resolved incidents over the past 90 days.
Where pages live
By default, every published status page is reachable at:<slug> is a short, URL-safe identifier you choose in the admin UI. If you skip choosing one at signup, Scaling 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:| Status | Meaning |
|---|---|
operational | Component is healthy. |
degraded | Component is slow or partially impaired. |
partial_outage | A subset of the component is down. |
major_outage | The component is fully down. |
maintenance | Planned maintenance is in progress. |
- Manual override set by an admin (e.g., to declare maintenance ahead of time).
- Open incident that tags the component — the worst severity wins.
- Default —
operationalif no override or incident applies.
maintenance is intentionally not escalating. A component in maintenance does not contribute to the overall banner being raised to degraded or worse.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:| Kind | When it appears | What customers see |
|---|---|---|
message | A responder posted a public update with a body. Optionally also carries a statusChange in the same write. | The full message body, the post timestamp, and (if present) the lifecycle transition. |
transition | A responder posted an internal update that carried a statusChange. The body stays internal; the status change is still public lifecycle state. | A bare row: “Status changed to identified” with a timestamp — no message body. |
redacted | A public update was redacted after posting. | The slot persists at the original timestamp, rendered as “This update has been removed.” Author identity is stripped on the public surface. |
Publishing requires component overlap
Responders who try to publish apublic 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: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
publicincident 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
maintenanceordegradedahead of time. - 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.