Multiple Status Pages, One Component Pool

Your API is degraded. Support is already posting in Slack. Marketing wants the customer-facing page updated. Internal IT wants a private view without the same wording. The lobby digital sign still shows all green because nobody had time to treat the wall like a second product.

That is the moment multiple status pages stop being a nice-to-have and start being architecture. The question is not whether you need more than one surface—a public URL, a restricted page, or a full-screen sign in the NOC. It is whether you are willing to maintain more than one timeline for the same outage.

Surfaces, not catalogs

Multiple status pages should mean extra branded surfaces, not extra catalogs.

In StatusDashboard, components live at organization scope. Each status dashboard is a public or private page with its own URL, design, access rules, and subscriber lists. The same dashboard can also publish digital signs for lobby or NOC monitors: full-screen status views that follow the components wired on that page, not a separate incident log you paste into by hand. On the dashboard Components tab, you choose which org components appear on the page (and on any signs tied to it). Order and grouping can differ per page.

When you publish an incident or maintenance event against those components, every dashboard that includes them picks up the same timeline. You declare once. Support does not copy updates between a customer page and an internal page. The lobby sign and the public URL stay aligned when they share components.

What stays separate is intentional:

• URL and domain (subdomain or custom domain per dashboard)
• Branding (colors, logos, custom code)
• Access control (public vs SSO- or IP-locked private dashboards)
• Subscribers and notification routing per dashboard

That split is the product story. Search results for "multiple status pages" skew toward aggregators, agency tools that sell one page per client, and suites that treat each page as its own component list. We built for teams that need several audiences without several incident workflows.

Jobs teams actually buy a second page for

One dashboard is enough for plenty of organizations. When a second surface pays for itself, it is usually one of these:

Public and internal

Customers need plain language and a subscribe flow. Employees may need the same incident with different detail, or a page behind SSO. Two dashboards, one component pool: post once, both timelines move.

One page per product or brand

If you ship three products to three buyers, one combined page often serves none of them well. Give each product its own URL and component subset while shared infrastructure (identity, billing, region) still updates from a single event.

Production vs staging

Staging should not inherit production traffic, but your team may still want a familiar status UI for dress rehearsals and comms drills. A separate dashboard with an overlapping or distinct component list keeps exercises off the customer URL.

Lobby and NOC digital signs

Wall monitors are not bookmarks to your marketing site. Each dashboard can publish digital signs at {host}/sign/{path}: full-screen views that track the same components you wired on that dashboard. When you update the incident in the admin console, the customer page and the sign stay in sync without a separate "sign timeline."

How it works in practice

1. Define components once in the admin console (Components): the services your org tracks (API, app, region, vendor, and so on).
2. Create a dashboard per surface (Dashboards): name, subdomain, optional custom domain.
3. Wire components on each dashboard's Components tab. Share some components across dashboards; keep others on only one page. Reorder and group independently per dashboard.
4. Publish events against affected components. Any dashboard that includes those components shows the event in its scoped history, active lists, and permalinks.

Fan-out is the point. Your comms lead owns the narrative once. The public page, the private SSO page, and the sign on the wall reflect the same declaration.

For wording during an active incident, The 5 Cs of Effective Outage Communication and status page best practices still apply. Multiple pages do not change the discipline; they remove duplicate typing.

When one page is enough

A second dashboard is worth adding when a real audience split shows up—not because "more pages" sounds mature on a roadmap.

One status dashboard is the right call when:

• You ship one product to one primary audience
• Internal staff can rely on the same public timeline (or your alert channel) without a separate URL
• You do not need a staging comms surface or a wall sign
• Your component list is small enough that splitting it would confuse visitors more than it helps

Most teams start with one dashboard and add another when a second URL, access model, or sign is an operational requirement—not a hypothetical someday.

Try it on your surfaces

If you already maintain separate timelines for customers and staff—or you are about to add a second product URL—walk through the flow with your org component list:

1. Create components that match how customers experience your stack.
2. Stand up a public dashboard and a private (or second branded) dashboard.
3. Wire overlapping components, publish a test maintenance event, and confirm both pages and any signs update together.

Start a free trial or talk to us if you need help mapping dashboards, signs, and access to how your org actually communicates during an incident.