Status pages

A status page answers "is it down?" before your customers have to ask. Unhandled builds it from your uptime monitors, adds the incidents and maintenance you post, and serves it on a public URL. Serving it on your own subdomain is coming soon.

Each environment of a project can have one status page. Most teams only publish production.

Create a status page

An environment needs at least one monitor before it can have a status page. Admins create and edit it.

What the page shows

Resources

Every monitor of the environment with Show on status page on appears as a resource, in the same order as on the Uptime page. Turn the setting off on monitors that customers should not see.

Each resource shows a status, 90 daily bars and its uptime over those 90 days.

The banner at the top reads All Systems Operational when every resource is operational, and shows the worst resource status otherwise. Maintenance ranks just above operational: the banner reads Maintenance in Progress only when nothing is degraded or down outside a window.

Checks that run during a maintenance window don't count toward uptime, neither as passed nor as failed.

Daily bars

Incident list

Active incidents and maintenance in progress come first, then upcoming maintenance, then up to 20 past incidents from the last 90 days. Each incident shows its severity, the affected resources and every update.

Incidents

Monitors never post incidents by themselves. An outage changes the resource status, and what you tell customers stays your call. Admins post incidents from the Incidents tab with Report new incident.

An incident starts now, or at an earlier time you set. Unhandled replaces a start time in the future with the current time, because only maintenance can be scheduled ahead.

Post updates as you learn more. Each update sets a status and adds a message, and on a public incident it can email subscribers the same way. Setting the status to Resolved moves the incident to the past incidents. Setting it back to another status reopens it.

Scheduled maintenance

An incident with severity Maintenance needs a start and an end, and the end must come after the start.

Cancel maintenance removes a window that has not started from the public page and keeps it in the Incidents tab as cancelled. It asks for a reason. To reschedule maintenance that has not started, use update_status_incident on the MCP server.

Caching

Unhandled rebuilds the public page at most every 15 seconds and sends it with this header:

cache-control: public, max-age=15, stale-while-revalidate=60, stale-if-error=86400

A CDN in front of Unhandled can keep serving the page for a day if the app has trouble. Saving the page, posting an incident or a monitor going down or up rebuilds it right away, though a cache in front may serve the old copy for up to 15 seconds.

The page keeps working when Unhandled's database doesn't answer. Each server keeps the last page it built and serves it, with Last updated showing when that copy was made. Unhandled also saves a plain copy of every public page and its feeds at least once a minute, and the proxy in front serves that copy when the app is down or failing. It shows the overall status, each resource, active incidents and maintenance, and when it was saved.

Feeds

Every public page has an RSS and an Atom feed with its incidents and maintenance, newest update first:

The page links both in its header, so feed readers find them from the page URL. Feeds are cached like the page.

Email subscribers

Visitors can subscribe to a public page by email with Subscribe to updates. They choose updates for every component or only for the components they pick.

Subscriptions use double opt-in. Unhandled emails a confirmation link that is valid for 7 days, and only confirmed subscribers receive updates. Every update email has an unsubscribe link. Subscribing again with a confirmed address changes nothing. A pending address takes the latest component choice. Each IP address can try 10 times an hour, and each email address 3 times an hour. A page also sends at most 30 confirmation emails an hour to addresses that have not confirmed yet, and 300 while one of its incidents is open. Confirmed subscribers never count toward that limit, so readers who confirm keep getting through.

A subscriber gets an incident update when the incident lists one of their components, or lists no resources at all. Update emails go out only when you leave Email N subscribers on while posting. They are retried like other notification emails.

The Subscribers panel in the status page settings lists the newest subscribers with their components and whether they confirmed. Admins can remove a subscriber there.

Custom domains

Serve the page on a subdomain you own, such as status.example.com, with a certificate issued automatically. Each status page can have one custom domain.

The domain must:

• Have at least three labels. Unhandled rejects apex domains like example.com and IP addresses.
• Not be verified by another organization, or already added in yours. An unverified domain in another organization does not block you.
• Not sit under one of Unhandled's own domains.

The page is served at the domain's root, https://status.example.com/, and only while the status page is public. Removing the domain stops serving it at once, and you can add it again later.

A custom domain serves the status page and nothing else. Every other path, such as /login, returns not found, and the domain never sets a cookie. That way a status domain cannot be used to sign people in to Unhandled.

Domain states

Unhandled rechecks active domains once a day. DNS lookups go through public resolvers, 1.1.1.1 and 8.8.8.8, so a stale cache on your network does not hide a correct record.

FAQ

Related