Creating public status pages

A status page is a public, unauthenticated page that shows the live state of a set of monitors — an overall banner, 90 days of per-monitor uptime history, and recent incidents. Visitors never see monitor targets, configuration or anything sensitive; only names, statuses and uptime numbers are rendered.

Your organization's handle

Every status page URL is namespaced by your organization's handle — a short, lowercase identifier (letters, numbers and dashes) that CompleteStatus generated from your organization name. You can change it under /settings/organization. Public pages live at:

https://completestatus.com/status/{handle}/{slug}

Because URLs are namespaced, page slugs only need to be unique within your own organization — every customer can have a page called status.

Warning: Changing your handle changes every status page URL immediately. Old links in the pre-2026 /status/{slug} shape keep redirecting to the new URL as long as the slug is unique across CompleteStatus.

Creating a status page

1. Go to /status-pages and click to create a page.
2. Choose the Project the page belongs to, then use Load monitors to list that project's monitors. (The project is fixed once the page is created — you cannot move a page between projects later.)
3. Fill in the fields:
   • Title — the public heading, e.g. "Acme — Service Status".
   • Slug — the URL segment. If you leave it blank it is generated from the title; letters, numbers, dashes and underscores only, unique within your organization.
   • Description — optional intro text shown on the page (up to 2000 characters).
   • Custom domain — optional; see below.
   • Monitors — tick the monitors to display, and optionally give each a group name (see below). Monitors from other projects can never be attached.
4. Set the branding options (see below) and leave Publicly visible on.
5. Save. The page is immediately live at its public URL (shown next to the slug field with a copy button).

Note: Turning Publicly visible off keeps the page and its configuration but makes the public URL return a 404 until you re-enable it. Deleting a page from the list at /status-pages removes it permanently.

What visitors see

• Overall banner — derived from the current status of the page's monitors: "All systems operational" when everything is up, "Some systems degraded" when any monitor is in maintenance, paused or pending state, and a down banner when any monitor is down.
• Uptime history — 90 days of per-monitor daily uptime bars, built from the daily rollups.
• Recent incidents — the latest incidents across the page's monitors, with the monitor name and timing.

Grouping services into sections

On every plan you can arrange a page's monitors into named sections — "API", "Websites", "Background jobs":

1. In the editor's Services shown card, type a group name next to each monitor. Monitors sharing a name render together; the field suggests names you've already used.
2. Save. Each group renders as a titled section with its own status chip (the worst status of its members); monitors with no group name list under "Other services" exactly as before.

Grouping is purely visual — the overall banner still reflects every monitor on the page.

Custom domains (CNAME)

On the Pro plan and up you can serve a status page on your own domain instead of the /status/{handle}/{slug} URL:

1. In the editor, set Custom domain to the hostname you want, e.g. status.yourcompany.com. Each domain can be attached to only one status page.
2. At your DNS provider, create a CNAME record pointing that hostname at your CompleteStatus host (the editor shows the exact target under the field).
3. Once DNS propagates, requests to https://status.yourcompany.com/ are answered with your status page at the root path.

The CompleteStatus URL keeps working alongside the custom domain. Only publicly visible pages are ever served on a custom domain.

For the full walkthrough — choosing a subdomain, registrar-by-registrar CNAME steps (Cloudflare, Namecheap, GoDaddy), verifying propagation and HTTPS — see Serving a status page on your own domain.

Warning: The domain must be a bare hostname (e.g. status.yourcompany.com) — no scheme, path or port. Invalid values are rejected with a validation error.

Password-protecting a page

On the Pro plan and up you can put a status page behind a password — ideal for client-only or internal pages that should stay off the open internet without managing IP lists:

1. In the editor's Password protection card, set a page password (minimum 6 characters). Leaving the field blank keeps the current password; tick Remove the password to clear it.
2. Save. Visitors now get a minimal password form (HTTP 403, never indexed) that reveals nothing about the page. After entering the correct password the page stays unlocked in their browser for 12 hours.

The password combines with the IP allowlist below — when both are set, a visitor must be on an allowed IP and know the password. Password attempts are rate-limited. Email subscribers are unaffected: incident emails are sent to verified subscribers regardless of the gates.

Note: Like the IP allowlist, an existing password keeps being enforced if your organization later moves to a plan without the feature (fail closed); changing or removing it again requires Pro or above.

Restricting access by IP (allowlist)

On the Business plan and up you can restrict who may view a status page — useful for internal dashboards or client-only pages that shouldn't be on the open internet:

1. In the editor's Access restriction card, enter one IP address or CIDR range per line — IPv4 and IPv6 both work, e.g. 203.0.113.10, 10.0.0.0/8 or 2001:db8::/32.
2. Save. Visitors whose IP isn't on the list get a minimal "This status page is restricted" page (HTTP 403) that reveals nothing about the page's contents; allowlisted visitors see the page as normal.

An empty list means no restriction — the page stays fully public. The restriction applies everywhere the page is served, including a custom domain.

Warning: Include your own IP so you don't lock yourself out — the editor shows your current IP under the field. If your office network changes IPs, prefer a CIDR range over a single address.

Note: An existing allowlist keeps being enforced even if your organization later moves to a plan without the feature (it fails closed rather than silently exposing the page); editing it again requires Business or above.

RSS feed and maintenance calendar

Every status page (all plans) publishes machine-readable feeds:

• RSS feed — /status/{handle}/{slug}/feed lists the page's incidents and maintenance windows as RSS 2.0. Ungated public pages advertise it via feed auto-discovery, so browsers and readers find it automatically.
• iCal calendar — /status/{handle}/{slug}/calendar.ics exposes upcoming and recent maintenance windows as calendar events you can subscribe to from Google Calendar, Outlook or Apple Calendar.

Both URLs are shown in the editor with copy buttons. If the page is password- or IP-protected, the URLs carry a private access token — anyone with the tokenized URL can read the feed, so share it only with people who may see the page. Public, ungated pages use plain URLs.

Status badge and embed widget

For pages that are public and carry no password/IP restriction (any plan):

• SVG badge — embed <img src=".../badge.svg" /> in a README or dashboard for a live "Operational / Degraded / Down" chip. Append ?uptime=90d to include the average uptime over that window. Responses are cacheable for 60 seconds.
• Embed widget — drop <script src=".../embed.js" defer></script> into any site to render a small floating status pill linking to your page. It sets no cookies and injects no third-party content.

Both snippets are shown in the editor. Restricted pages intentionally return 404 on these endpoints so their status can never leak through an image or script tag.

Audience-specific views (Agency)

On the Agency plan you can carve one status page into per-audience views — each client or team gets a signed URL showing only their services. See Audience-specific status views for the full guide. (Atlassian Statuspage sells audience-specific pages for $300/month; on CompleteStatus they're included in Agency.)

Branding

Every plan gets the same status-page branding controls:

• Primary color — a hex color used for accents on the public page.
• Dark theme — toggle a dark variant of the page.
• Logo — upload an image (max 1 MB) shown on the public page in place of the default heading treatment.

Branding is per-page, so an agency can give each client's page its own look.

Email subscribers

Each public status page includes a Subscribe to updates form. The flow is double opt-in:

1. A visitor enters their email address and presses Subscribe. The endpoint is rate-limited to prevent abuse.
2. CompleteStatus emails them a verification link; the subscription is inactive until they click it.
3. Verified subscribers can leave at any time via the one-click unsubscribe link, which removes them immediately.

The status-page list at /status-pages shows the count of verified subscribers per page, so you can see how many people are watching each page.

Plan limits

The number of status pages per organization is set by your plan:

Branding, grouping, feeds, badges and email subscribers are available on every plan. Custom domains and page passwords require Pro or above, the IP allowlist requires Business or above, and audience-specific views are Agency-only — see pricing for the full comparison.

Related guides

• /docs/status-page-audiences — signed per-client views of one status page (Agency).
• /docs/livestatus-walls — for the office TV: a full-screen, auto-refreshing wall of the same monitors, no login needed.
• /docs/custom-domain-status-pages — step-by-step CNAME setup for your own domain.
• /docs/incidents-and-escalation — the incidents your page displays.
• /docs/maintenance-windows — muting alerts during planned work (these feed the iCal calendar).
• /docs/reports — SLA evidence you can share alongside a status page.

Further reading: Status page best practices and Why your status page can't live on your own infrastructure on the blog.