Public status pages

A status page surfaces the live health of your services to your customers. Every plan includes at least two pages; a page can be public, password-protected, behind an access code, restricted to invited viewers, or any combination.

Create pages in the WebUI at Status pages → New status page.

Plan availability

	Free	Starter	Pro	Business
Status pages	2	5	15	50
Subscriber notifications	✓	✓	✓	✓
Custom domain (CNAME)	—	—	✓	✓
White-label branding	—	—	✓	✓
Password protection	—	—	—	✓
Custom design (CSS/logo)	—	—	—	✓
Status page analytics	—	—	—	✓

Extra status pages are available as an add-on on Pro and above.

URL

A page lives at <your-app-domain>/status/<slug> by default. The slug — lowercase letters, numbers, and hyphens — is set at create time and editable from page settings. An enabled toggle takes the whole page offline without deleting it.

Custom domains (Pro+)

A custom domain serves the page from your own hostname, e.g. status.yourcompany.com:

Add the domain in page settings. It must be a subdomain (status.example.com, not example.com), and each domain can serve only one status page.
Create the CNAME record shown — your domain → status.pathwatch.app.
PathWatch checks the DNS automatically every few minutes. Once the CNAME resolves, the domain is verified and an SSL certificate is provisioned automatically — no certificate work on your side.

Page settings show the live verification and SSL status. If the CNAME hasn’t appeared within 7 days, the pending domain is removed and you’ll need to add it again. Removing a domain takes the hostname off your page immediately; the certificate is revoked shortly after, so re-adding the same domain within the hour may briefly wait on that cleanup.

Layout: sections and components

A status page is a vertical stack of top-level blocks whose order you control by dragging in the editor: the status bar (overall state), maintenance (active and upcoming windows), components, and incident history.

Within the components block, sections group related components under a heading. A section has a name, an optional description, and a collapsed by default toggle for sections visitors usually don’t need to expand. Components can live inside a section or stand alone, and both sections and components are freely reorderable.

Component types

A component is the actual rendered widget. Fifteen types are available:

Component type	Renders
`monitor`	A single monitor’s current status and uptime bar. Optionally shows incidents related to the monitor.
`uptime_overview`	Aggregated uptime percentage across multiple monitors.
`metrics_overview`	Latency / response-time charts.
`ssl_certificates`	Certificate expiry for monitors with SSL checks.
`certificate_changes`	Recent certificate changes (issuer, fingerprint) detected by SSL checks.
`domain_expiry`	Domain registration expiry for domain monitors.
`keyword_checks`	Latest keyword-check results.
`incident`	One specific incident, pinned — useful for an ongoing major incident.
`incidents_list`	Current/recent incidents as a list.
`incident_history`	Past-incident timeline, filterable by severity and time window.
`maintenance`	Active and upcoming maintenance windows.
`announcement`	Free-text banner.
`description`	Free-text block for context (“This page covers our EU platform”).
`link`	An external link (your support portal, docs, social).
`divider`	Visual separator.

Every component has a display name, an optional description, an optional group label, and a sort position. Monitor-backed types take the monitor to display; the incident type takes the incident to pin. Type-specific options (e.g. severity and time-window filters on incident_history) are configured in the component’s settings panel.

Page display toggles

Per page, in settings:

Toggle	Effect
Banner incident	Pin one incident as a banner across the top of the page.
Show maintenance	Show or hide the maintenance block.
Show incident history	Show or hide the history block.
Expandable component incidents	Let visitors expand a component in place to see its related incidents.

Visibility and access

A page has one or more access methods enabled (at least one is required). Methods combine — visitors get in via any enabled method.

Method	Audience
Public	Anyone with the URL. The subscribe form is shown.
Access code	Visitors must supply a code (`?code=` in the URL, or pasted on the gate page). Generate, rotate, or remove the code from page settings — rotating re-locks the page.
Password (Business)	Anyone who knows the page password (4–128 characters). Visitors enter it once on the gate page. Set, change, or remove it from page settings.
Login (invited viewers)	Only people you invite by email. See below.

The subscribe form is shown only on public pages — access-code, password, and login-gated pages hide it. Switching methods doesn’t remove existing subscribers; they keep receiving notifications.

Invited viewers

With the login method, you manage a viewer list per page:

Invite a viewer by email from page settings. They receive an invitation email with a direct access link — no PathWatch account needed.
A viewer who has lost the link can enter their email on the gate page; if (and only if) the address is on the viewer list, a verification code is emailed to them, and entering it unlocks the page.
Remove a viewer at any time from the same list to revoke access.

Viewers are page-scoped: inviting someone to one status page grants nothing on your other pages or in your PathWatch organisation.

Themes and branding

Each page has branding settings: page/header/footer/card colours, accent colour, logo URL, favicon URL, and header/footer text.

Theme templates apply a complete colour set in one click and are available on all plans. Editing the branding fields afterwards detaches the page from the template so your tweaks stick.
White-label (Pro+) removes PathWatch branding from the page.
Custom design (CSS/logo) (Business) unlocks fully custom styling beyond the standard branding fields.

Status page analytics (Business)

Business plans include visitor analytics per status page — page views, unique visitors, and geographic distribution — so you can see how many customers are checking status during an incident.

Subscribers

Visitors to a public page can subscribe to updates:

They enter their email in the subscribe form.
PathWatch sends a verification email — the subscription only starts once they click the confirmation link (double opt-in), so nobody can subscribe an address that isn’t theirs.
Subscribers receive an email when an incident is opened, updated, or resolved, and when a maintenance window starts.

Every notification carries an unsubscribe link. Cancelling from the verification email also blocks re-subscription attempts for that address for an hour, so a mistyped address can’t be spammed with verification mail.

Incidents

Status pages link to incidents you create from Incidents → New incident. Linking an incident to a page puts it in the page’s incident components and history (and optionally the page banner) — you don’t have to duplicate the writing between an internal incident record and what your customers see. Incident updates push to subscribers automatically.

Tips

Keep components surface-level. Customers want “Is checkout working?”, not “What’s the p99 latency of the payments service?”.
Pair an incidents_list component with an announcement for current-incident comms — the announcement is the headline, the list is the record.
Use sections with collapsed by default for second-tier services so the page opens to what matters.
Custom-domain pages should still link back to your main domain in the footer — visitors landing on status.yourbrand.com during an outage often need a “home” link. The link component does this.