> ## 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.

# Publish a Status Page

> Configure a public status page, pick the components to display, and publish it to your customers.

This guide walks you through configuring a public status page for your organization, selecting the components your customers should see, and publishing it.

<Frame caption="A configured status page ready to publish">
  <img src="https://mintcdn.com/scalingcloud/5-FlXcH6ySIwHzG0/images/placeholder.svg?fit=max&auto=format&n=5-FlXcH6ySIwHzG0&q=85&s=18ab9c45531fe92b117df1f9652cb357" alt="Status page configuration" width="1200" height="675" data-path="images/placeholder.svg" />
</Frame>

## Prerequisites

* One or more [components](/concepts/components) in your catalog. You can create them inline from the status page settings, but having them ready makes the flow faster.
* The **Admin** role in your organization.

<Steps>
  <Step title="Open status page settings">
    Go to **Settings → Status Page** in the scaling.cloud dashboard.

    If you haven't configured a page before, scaling.cloud has already created a draft for you with a default slug (`org-<8-hex>`). The page is **not** published yet — customers won't see it.
  </Step>

  <Step title="Choose a slug">
    Pick a short, URL-safe identifier for your status page. The slug is part of the URL:

    ```
    https://scaling.cloud/status/<slug>
    ```

    The slug must be unique across all scaling.cloud status pages. Lowercase letters, numbers, and hyphens; up to 63 characters.

    <Tip>
      Use your product or company name (e.g., `acme`, `acme-platform`). Avoid changing it later — customers may bookmark or embed the URL.
    </Tip>
  </Step>

  <Step title="Select components to display">
    In the **Components** section, pick which components from your catalog should appear on the page.

    Components are grouped on the page by their `groupLabel`. To group them, set a `groupLabel` (e.g., `Platform`, `Payments`) on each component in **Settings → Components**.
  </Step>

  <Step title="(Optional) Set manual overrides">
    For planned maintenance or a known issue you want to surface separately, set a component's status manually:

    * **Maintenance** — declare planned maintenance on a single component. The overall banner reads **Under maintenance** while it's set.
    * **Degraded / partial outage / major outage** — force a status that takes precedence over the live incident-derived status.

    Manual overrides win over incident-derived status. Use the **Clear override** button to return the component to its automatic status.

    <Tip>
      To announce planned work as a titled notice with its own time window spanning several components — rather than flipping one component's status — schedule a [maintenance window](/guides/schedule-maintenance-window) instead.
    </Tip>
  </Step>

  <Step title="Publish">
    Toggle the **Published** switch at the top of the page settings.

    Your page is now live at `https://scaling.cloud/status/<slug>`. Share the URL with your customers, embed the JSON feed at `https://scaling.cloud/api/public/status/<slug>` in your help center, or attach a [custom domain](/guides/connect-custom-domain) like `status.example.com`.
  </Step>
</Steps>

## Verify the page

Open the URL in an incognito window (no scaling.cloud account needed) and confirm:

* The overall banner reflects the current health.
* Components are grouped as expected.
* The header and component names match your brand voice — these are customer-visible.

## Unpublishing

Toggle **Published** off at any time. The page immediately returns a 404 for new requests; the CDN cache (30 seconds) flushes shortly after.

## Publishing your first incident update

Once the page is live, the next thing your team will want to do during an incident is **post a public update** — a customer-visible message that lands on the status page. This is a separate, deliberate action from filing the incident itself.

You can publish from three surfaces:

| Surface   | How                                                                                                                                                                                                                                     |
| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Web       | Open the incident detail page → the post-update form has a visibility toggle. Switch to **public**, write the message, optionally pick a `statusChange`, click **Publish update**. The form previews the target Status Page URL inline. |
| Slack     | `/scaling publish <incidentId>` opens a modal with a multi-line body field and target-URL preview. See [Slack — Slash commands](/integrations/slack#slash-commands).                                                                    |
| API / IaC | [`POST /v1/incidents/{id}/updates`](/api/incidents/updates-put) with `visibility: 'public'`.                                                                                                                                            |

Every surface defaults to `internal`. Publishing is always an explicit choice — you cannot accidentally push staff chatter to customers.

### NO\_PUBLIC\_SURFACE — what it means and how to avoid it

A `public` update is rejected with `NO_PUBLIC_SURFACE` when the incident's **affected components** don't overlap any **selected components** on a published Status Page. Two common causes:

* The incident was filed without `componentIds`, so it has no components to match against.
* The components on the incident aren't on this Status Page's selected list.

Fix by either tagging the incident with one of the page's components, or extending the page to include the incident's components.

For the full data model (visibility, redaction, the render rule on the public page), see [Incidents — Incident Updates](/concepts/incidents#incident-updates).

## Next steps

* [Schedule a maintenance window](/guides/schedule-maintenance-window) to announce planned work ahead of time.
* [Connect a custom domain](/guides/connect-custom-domain) so your page is served at `status.example.com`.
* Read [Public status pages](/concepts/status-pages) for how component status is derived from overrides and open incidents, and how the public timeline renders.