When something breaks, your status page gets more traffic in ten minutes than your marketing site gets all day — from your most stressed, least patient audience. It's also the page that support links in every "is it just me?" reply, that enterprise procurement checks before signing, and that your own team refreshes during a deploy.
Yet most status pages are an afterthought: a default-styled list of green dots, updated by hand when someone remembers, with no history and no way to tell planned work from an outage. This guide is everything we've learned building status pages into WatchFor — organized as decisions you'll actually face, from cosmetics to trust mechanics.
Make it yours: identity and theme
A status page is an extension of your product, and the first signal of trustworthiness is that it looks like your product, not like your monitoring vendor:
- Your own address. Every WatchFor page lives on a subdomain derived from the name you pick —
yourname.watchfor.io— shareable in one line of a support reply. - Logo, positioned your way — left, center or right in the header, matching your site's layout.
- Theme: light, dark, or auto. Auto follows each visitor's system preference — the right default, because a developer checking your API status at 2am is in dark mode, and your marketing lead screenshotting the page for a customer deck is not.
- Name and description set the tone at the top of the page — one sentence of what this page covers is enough ("Live status for the Acme API, dashboard and integrations").
None of this affects the data, but it decides whether visitors read the page as official. An unbranded status page invites the question "is this even theirs?" at exactly the wrong moment.
Structure: components, not monitors
The biggest mistake teams make is exposing their monitor list directly. Customers don't care about api-lb-2 healthcheck; they care about "API". A component is the translation layer: one customer-recognizable service, backed by one or more monitors, its state derived from theirs.
WatchFor gives each component (or group) three display modes, and choosing well is most of the design work:
| Mode | Shows | Use for |
|---|---|---|
| Rolled-up | One aggregate indicator for the whole group | Regions, infrastructure your customers see as a single thing |
| Collapsible group | Aggregate that expands to per-part detail | "Integrations" with a dozen members — headline first, detail on demand |
| Expanded | Every part, always visible | The 3–5 core services everyone checks first |
A good page reads top-to-bottom in decreasing granularity: core services expanded, secondary clusters collapsible, plumbing rolled-up. Ten lines, not a hundred — with the hundred still reachable in two clicks.
Each component keeps its own uptime history, feeding the heatmap visitors use to answer the second question they always have: "is this a one-off, or are they always down?" (A small honesty option here: dim untracked days — days before you started monitoring a component render visibly muted instead of pretending they were 100% green.)
Automatic or manual? Both, with clear rules
Pure-manual status pages die of neglect — the outage ends at 3am and the page says "investigating" until someone remembers at 10. Pure-automatic pages occasionally say something you're not ready to say publicly. The workable answer is automatic by default, manual where judgment matters:
- Component states follow their monitors — an incident confirmed across locations flips the component, recovery flips it back. Nobody has to remember anything at 3am.
- Auto-publish is a per-page choice. Want a fully hands-off page? Leave it on. Running a carefully-worded enterprise page? Turn it off and publish incidents deliberately.
- Manual state override exists for when reality is ahead of the checks — flagging a degraded third-party dependency before your own monitors catch it, or holding a component "degraded" while you verify a fix.
- Incident updates are human. Automation opens and closes the entry; the narrative — Investigating → Identified → Monitoring → Resolved — is yours, and incident templates keep the wording consistent when the person writing is also the person firefighting.
The division of labor: machines handle state, humans handle story.
Third-party dependencies: answer "is it you or them?"
Half of "your" outages are Stripe, GitHub, Cloudflare or AWS having a day. When that happens, your support queue fills with tickets that aren't yours — unless your status page answers the question preemptively.
Third-party components mirror an external provider's own status page, live, next to your components. Pick the provider from the catalog (GitHub, Cloudflare, Stripe, OpenAI, Slack, Google Cloud and dozens more), choose the specific parts you rely on — e.g. GitHub Actions and Webhooks, not all of GitHub — or show the provider's overall status as one line. Status refreshes automatically every few minutes, each component links to the provider's page, and a 30-day history builds up so visitors see the provider's track record too.
One rule keeps this honest: a provider's outage never flips your page's overall banner. Your "all systems operational" reflects the services you run; the third-party row shows the dependency problem in place. Anything else would let you blame vendors for your own reliability — or worse, inherit their red banner when your service is actually fine.
Maintenance: announced from one source of truth
Planned work on a status page has a classic failure mode: the notice is posted by hand, separately from the alert suppression, and the two drift. WatchFor wires them together — a maintenance window with "announce on status pages" enabled posts the notice itself:
- it appears ahead of time with your description and schedule,
- it lists the affected components automatically — derived from the monitors the window actually covers, so the announcement can't disagree with reality,
- it tracks its own lifecycle: Scheduled → In progress → Completed, moving if you extend the window and closing when you complete it.
And deliberately, there is no "declare maintenance" button on the status page itself — planned means planned in advance, so an unplanned outage can't be relabeled after the fact. Your maintenance history stays meaningful because it can't be gamed. For work on things you don't monitor (a payment provider's scheduled downtime, an office move), an announcement-only window posts the notice without touching any monitor.
Who can see it: three visibility modes
Not every status page is for the world:
- Public — the customer-facing default. Indexed, shareable, with an RSS feed subscribers can follow.
- Password-protected — a public URL behind a shared password, for partners, big customers or staging environments.
- Private — visible only to your organization; an internal ops dashboard that never leaks.
Run several at once: a public page with the customer-friendly component set, and a private one with the warts-and-all detail your team actually needs. (Password-protected and private pages don't expose RSS or badges — a feed can't carry a password, and a badge would leak your status to anyone with the URL.)
Meet people where they are: badge, JSON, RSS
The best status page is one customers see before they come asking:
- Status badge — an SVG pill showing live overall status ("All systems operational" / "Major outage"), embeddable in your docs, dashboard or README with a copy-paste snippet, in dark, light or auto theme, linking back to the page.
status.json— the page's full state (overall status, per-component states, active incidents and maintenances) as a CORS-enabled JSON endpoint. Build your own in-app banner — "We're aware of an issue" inside your product during an incident is the single highest-value integration a status page has.- RSS — for the people and tools that want a subscription rather than a poll.
The trust rules, collected
Strip away the features and a status page succeeds on exactly one axis: do people believe it? Every mechanism above serves a handful of rules worth stating plainly:
- Update automatically — a page that lags reality trains people to check Twitter instead.
- Confirm before declaring — flapping between red and green is worse than being briefly wrong; WatchFor only flips state on multi-location-confirmed incidents.
- Show history — a component heatmap with real data (and honestly-dimmed untracked days) beats any wall of text about your reliability culture.
- Separate planned from unplanned — and make the planned kind impossible to fake retroactively.
- Don't inherit vendor outages, don't hide them either — their row, their color; your banner, your services.
- Write updates like a human — timelines and templates exist so the 3am update is calm, specific and consistent.
A status page built this way stops being a checkbox and starts doing real work: deflecting tickets, shortening incidents ("mitigation is deployed, monitoring" answers a hundred emails at once), and quietly passing every procurement review that asks "do they take reliability seriously?"
Status pages are included in every WatchFor plan — the feature overview shows the full picture, and the docs walk through setup in about a minute per page.