> ## 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. # Public Status Pages > Publish a public status page so customers can see component health and active incidents in real time. 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](/concepts/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 ## Where pages live By default, every published status page is reachable at: ``` https://scaling.cloud/status/ ``` The `` 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](/guides/connect-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. | 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](/concepts/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: ``` major_outage > partial_outage > degraded > maintenance > operational ``` 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//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](/concepts/incidents#redacting-a-published-mistake) after posting. | The slot persists at the original timestamp, rendered as **"This update has been removed."** Author identity is stripped on the public surface. | 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](/concepts/incidents#origin-human-vs-system) 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: ``` GET https://scaling.cloud/api/public/status/ GET https://scaling.cloud/api/public/status//history ``` Neither endpoint requires authentication. The live snapshot includes a `maintenances` array of scheduled maintenance windows — see [Scheduled maintenance — In the JSON feed](/concepts/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/`. * **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](/concepts/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](/concepts/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 For a step-by-step walkthrough, see [Publish a status page](/guides/publish-status-page).