This guide walks you through configuring a public status page for your organization, selecting the components your customers should see, and publishing it.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.
Prerequisites
- One or more 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.
Open status page settings
Go to Settings → Status Page in the Scaling dashboard.If you haven’t configured a page before, Scaling 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.Choose a slug
Pick a short, URL-safe identifier for your status page. The slug is part of the URL:The slug must be unique across all Scaling status pages. Lowercase letters, numbers, and hyphens; up to 63 characters.
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.(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. Maintenance does not raise the overall page banner.
- Degraded / partial outage / major outage — force a status that takes priority over the live incident-derived status.
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 like status.example.com.Verify the page
Open the URL in an incognito window (no Scaling 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. |
| API / IaC | POST /v1/incidents/{id}/updates with visibility: 'public'. |
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
Apublic 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.
Next steps
- Connect a custom domain so your page is served at
status.example.com. - Read Public status pages for how component status is derived from overrides and open incidents, and how the public timeline renders.