Status pages

A status page is a page about the service, published for people who have no account: your customers, your visitors, anyone holding the address. It lives on the same Webmonit server, at an address of the form /status/something, and it opens without a sign-in.

It exists to answer one question, asked by somebody who is not going to investigate: is it me, or is it them?

What is on it#

At the top, a banner with the one-line answer — All systems operational, Some systems are degraded, Some systems are down, or Maintenance in progress — with the time it was computed and how often it refreshes itself.

Under it, the components: categories the admin named, each holding a few lines. A line is one thing a visitor can care about, wearing the label the admin gave it — "Web hosting", "Mail", "Name servers" — and never a machine's name unless the admin chose to write one. Each line carries a word (Operational, Degraded, Down, Maintenance, Not served here, No data), a strip of small bars, and an availability figure.

The bars are the recent past, one bar per hour or per day depending on how far back the admin set them to reach — twenty-four hours by default. Green bars are hours or days with nothing wrong; amber and red ones are not. The figure beside them is the share of the measurements that did not find the thing down, over the period measured, and the page says which period that is.

A line that stands for several machines doing the same job does not go red because one of them fell. It reads Partial — 2 of 3 operational, which is the truth: the service is standing, with less behind it. Lines fold shut while everything under them is well and open by themselves when something is not, so a visitor never has to click to find what is wrong.

Where the admin asked for it, a line can carry a small chart of the last 24 hours: the typical response time of the sites, the network round trip to the machines, or the DNS queries answered per second.

Then, if any are declared, the maintenance announced ahead — ongoing ones first, then the planned ones within the next fortnight by default — each with the title and the note the admin wrote.

And at the bottom, the incidents: the last ninety days by default, each with its state (ongoing or resolved), when it opened, how long it lasted, and the words written for the public. When there are none, the page says "No incident to report", which is the whole point of publishing one.

What it never shows#

A status page is not a smaller version of the interface. What it does not carry, it does not carry by design.

It shows no figure about anybody else's targets. It shows nothing about what the machines are doing inside — their load, their disks, how long they have been up: that is the admin's business and nothing a visitor could act on. It shows no evidence from an incident — no page bodies, no headers, no error detail beyond the sentence written for the public. And nothing else on the server is reachable from it: there is no link inward, no listing, no search. A visitor who follows the address gets that page and only that page.

An incident appears there only if the admin explicitly published it, and then in the words they wrote for that purpose — a public title and a public note, separate from the technical summary the interface shows. An incident nobody published does not exist on the status page, however loud it was inside.

Publishing an incident#

What the page says happened is written by the admin, from History › Published in the interface — never on the public page itself. Two ways in:

• From a measured incident: in History, each incident carries a Publish button (and its own page a Publish on the status page one). The form opens with the subject, the time it opened and, if it is over, its resolution already filled in.
• By hand, with Declare an incident, for what nothing measured — a provider's incident upstream, a cause seen from outside, a period the checks slept through.

Either way the form asks for the page it goes on (or every page), an impact — Outage, Degraded performance or Notice — a title, what it touched (groups, machines, sites), and a first update: a status and a few lines. The page names what was touched by the labels it gives those things, "Name servers" rather than a machine's name, unless the box name the machines is ticked.

Then the incident lives: each update posted from its page in the interface carries a status — Investigating, Identified, Monitoring, Resolved — and the words that go with it. Resolved closes it at that time; any other status reopens it. An update can be corrected or removed afterwards, the first one excepted, since a timeline has a beginning.

On the status page, an open incident is at the top with its impact, its status, its latest update and what it affects; a resolved one is among the past incidents, with how long it lasted. Each has an address of its own, /status/something/incidents/N, with the whole timeline. A published incident is words and dates: it carries no evidence, and changes no availability figure — the bars say what was measured, the incident says what happened.

For a site or a client area that wants to say "there is an incident" without reading the page, /status/something/incidents.json answers, without any token, with the open incidents and their updates; ?days=30 adds those resolved in the last thirty days.

Who decides what is on it#

The admin, entirely: the page's address, its title, the sentence under it, which categories exist and which lines go in them, what each line is labelled, how far back the bars reach, how many days of incidents are listed, how far ahead maintenance is announced, and how often the page recomputes. They also decide, per line, whether the machines behind it and the services on them are shown when a visitor unfolds it.

Creating and editing status pages is an admin function. A customer account, read-only or not, does not build one — but it can be given the address of one, and so can that customer's own customers.

Reading one honestly#

Green on a status page is a promise about what the line is measured by, and nothing wider. If the line stands for a group of machines, green means those machines answer; it does not certify that a particular site on one of them is serving the right page. Your site's own page inside the interface is the finer instrument; the status page is the public one.

The availability figure is a share of measurements, not a legal statement. A gap in the bars means nothing was measured then, not that everything was fine.

And the page is built to survive the day it is needed. It is recomputed at most once per its own pace — every thirty seconds by default — and served from that one copy to everyone, so a thousand people arriving at once cost one computation. It re-reads itself with a plain HTML refresh and needs no script to work at all, because a status page that fails when the platform is in trouble is worse than no status page.