Running & Maintaining a Site

Status Page

Definition

A status page lists the parts of a service — the site, the uploads, the API, the dashboard — with a current state against each, plus a reverse-chronological log of incidents. Each incident entry usually moves through investigating, identified, monitoring and resolved, with a timestamped note at every step. Many status pages also publish rolling uptime figures for the last 30 or 90 days. The important design rule is independence: if the status page runs on the same infrastructure as the service, it goes down with it, which is exactly when people need it. Because it is a handful of text and a little CSS, a status page is the archetypal static page, and is often deployed to a different provider and a different domain from everything else.

Why It Matters

During an outage, support volume rises faster than the fault is understood, and every message asking whether it is just them takes time away from the fix. A page that answers that question absorbs most of it. Silence is read as either incompetence or indifference, and an entry that says only that engineers are investigating, posted within ten minutes, holds people far better than a perfect explanation posted two hours later. The incident history matters afterwards too: a prospective customer comparing providers will read six months of honest write-ups more generously than a page with no incidents at all, which reads as a page nobody updates.

How It Works

Keep it on a subdomain such as status.example.com, with DNS at a different provider from the main site where you can manage it, so a failure at one does not take both. Feed it from your uptime monitoring so the component states change without anyone typing, but keep manual posting for the narrative, because only a person can say what is happening and when the next update will come. Every entry needs three things: what is affected, what is not affected, and the time of the next update — then keep that promise even when there is nothing new to report. Mark the incident resolved explicitly rather than letting it fade, and add a short follow-up within a few days for anything that lasted more than an hour. Offer subscription by email or RSS so people can stop refreshing.

Real-World Example

A small SaaS keeps its marketing site and app on one platform and publishes its status page as a plain HTML file at meridian-status.99helpers.site, mapped to status.meridian.app on a custom domain. When their main provider has a regional failure and everything else goes dark, the status page is unaffected because it shares nothing with them. Ninety minutes of incident notes go up in five short entries. Support tickets for the outage total eleven, against more than forty the previous time, when the only working channel was a post on social media.

Common Mistakes

  • Hosting the status page on the same infrastructure as the service — it is unreachable precisely when it is needed
  • Going quiet mid-incident because there is nothing new to say, which reads to customers as the problem being abandoned
  • Marking components green while users are still affected, usually because the fix was deployed but caches had not cleared
  • Never posting anything, so the page becomes a page nobody trusts and support goes back to answering the same question one message at a time

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →