Status pages

A status page is a public page WireWatch serves on your behalf. It needs no login, it is safe to put in an email or on a login screen, and it exists so that an outage does not become an inbox full of “is it down?”.

You build one from components — named groups of your monitors — and you write updates on it by hand while something is going wrong. Your monitors themselves never appear on it.

The URL your readers open

A page lives at <public status base>/<slug>. The base is the origin this deployment serves public pages from; the slug is the one you chose when you created the page.

The API composes that URL and hands it back to you — the dashboard never assembles it from parts. If the deployment has no absolute http(s) base configured, the API refuses to compose a link at all rather than handing you one that resolves against whatever host happens to be showing it.

You can also serve the same page from a name of your own, such as status.acme.com. That is a custom domain, it does not replace the slug URL, and it only carries traffic once it has been verified.

The slug is global, not yours

A slug is unique across every organisation on WireWatch, not just yours. The public URL is not scoped to your account, so the name has to be free everywhere.

Creating or renaming a page onto a taken slug is refused with 409. That answer is the same whether the slug is held by one of your own pages or by a stranger’s: you are not told which, and you cannot use the endpoint to discover whether some other company has a page called status. Pick something that names you — your product, your company — rather than a word everyone wants.

published — until you set it, nothing exists

A new page is created unpublished, and unpublished is the default rather than a step you have to undo.

An unpublished page is not “an empty public page”. It is not composed at all: the process that builds public pages only ever reads published ones, so an unpublished page has no public snapshot for the public URL to serve, and the URL answers 404. Unpublishing a page that was live puts it back in exactly that state — the URL stops answering, and it stops answering the same way an unknown slug does.

Unpublishing stops the e-mail as well. An update posted to an unpublished page is still recorded but reaches no confirmed subscriber, and the page keeps the subscribers it collected while it was public.

So the order that works is: create the page, add its components, write whatever you want readers to see first, and publish last.

A published page also serves two machine-readable surfaces beside the HTML — snapshot.json and an RSS feed. Both are described in feeds and snapshots.

Branding

A page can carry an accent colour of your own, and can have WireWatch’s own branding removed from it altogether. Both are plan-gated, on two different plans, and both are described on appearance and branding — including what happens to them when your plan changes.

Components

A component is a named, ordered group of your monitors — “API”, “Dashboard”, “Email delivery”. It is the unit a reader sees: one name, one description, one status. Components appear in the order you set, and reordering them is a first-class operation rather than a rename trick.

A component holds monitors by mapping them to it. A monitor can be mapped to more than one component, and a component with no monitors mapped is legal — it simply has nothing to derive from. You can only map a live monitor of your own organisation; anything else is refused as not found, with no hint that it might exist somewhere else.

What a component’s status is derived from

A component stores no status. Every time the page is composed, WireWatch reads three things from the monitors mapped to it:

• activeMonitorCount — how many of those monitors are running at all.
• openSeverities — the severities of the incidents currently open on them. What opens one, and what closes it, is detection’s business and is described there.
• maintenanceCovered — whether any of them is inside an active maintenance window.

activeMonitorCount, openSeverities, maintenanceCovered all read the same set: mapped monitors that are active and not deleted. That is one rule, not three coincidences. A monitor you pause and a monitor you delete leave the component’s derivation entirely — out of all three at once, never out of one of them — so a component whose monitors are all paused reads as having no data rather than as being down.

What a reader never sees

No monitor identity ever reaches a reader. The tree the public page is built from carries, per component, the three values above and nothing else about a monitor: no name, no id, no URL or host, no check type, no interval, no assertion, no incident cause. Those three values are consumed while the status is worked out and are not published either — a reader sees a component’s name, its description and its status, and never a count or a severity.

That is a property of what the page is built from, not a filter applied late. There is no setting that turns it off and nothing you can map that leaks a monitor onto it, so a page is safe to hand to a customer who must not learn how your system is put together.

Who may do what

Permission	Held by
status_page:read	Owner · Admin · Editor · Billing
status_page:manage	Owner · Admin

Creating a page, editing its components, mapping monitors, posting updates and publishing are all the second one. Everything else — opening the screen, reading a page you already have — is the first.

A Viewer holds neither, and so cannot see status pages at all. This is the one place in the product where a Viewer sees nothing rather than a read-only version of it, and the one place where a Billing user sees more than a Viewer does. If the status-pages screen is not there for you, your role is the reason, and the fix is a role change rather than a bug report.

The public page itself is not covered by any of this. It has no login, so no role applies to it: a published page is readable by anyone with the link, including people who have no WireWatch account.