How to publish a status page that draws itself from your monitors

What a status page is for

A status page answers one question before anyone asks it: is it you, or is it me? When the checkout is slow, the first thing a customer, a colleague or a client does is look for a page that says so. If there is none, they write to you, and you answer the same question thirty times while fixing the thing. A public page that draws itself from the monitors you already run answers it once, in the same minute the monitors notice, and keeps answering while you work.

hostnag's own page, hostnag.com/status/hostnag, is a real one over hostnag's own monitors: the site, the app, the ping probes and the services behind them, drawn the same way yours would be. Each page belongs to one zone and lives at hostnag.com/status/<slug>. It shows every monitor you pick under a public name, with its word (Up, Down, Degraded, Expiring soon), its uptime figures, a strip of the last day or month, the incidents and the maintenance you have planned. Apart from the incidents you choose to write, nothing on it is typed by hand.

Publish one

Open the zone's ⋯ menu and choose Status page (setting one up is for admins and owners), give the page a slug and a title, and mark it Published. The status pages feature page shows the result over sample data, with every setting and both badges. One page per zone; 1 on Free, 10 on Pro, as many as you like on Business. The slug is the address, so pick the one you would put in a footer: acme, not acme-status-page-2. A few words are reserved (status, api, login and the like) and a slug another org holds is taken.

Then pick the rows. A new page starts with every monitor of the zone; the Monitors tab is where things come off, and where each row gets its public name. That name is all a visitor sees: the hostname, the URL, the port and every error string stay inside the app. "Checkout" is a public name; api.acme.example/health is not.

What each row shows

A row is a lamp, a name and a word. For a tracked monitor (a website, a port, a DNS record, a ping, a heartbeat, a vendor page) the right-hand figure is uptime over 30 days. Under the name, the Figures setting shows either a typical response time for the last day or the 24 h and 7 d uptime with p50 and p95. A certificate or a domain shows its days left instead, and, while the page draws strips, its runway: the validity window with the spent part muted and the rest coloured by the row's own word.

The strip is the same recorder the History page draws: one cell per hour over 24 h and 7 d, one per day over 30 d and 90 d, coloured up, blip (a bad minute or two inside an hour that stayed at or above 99 %) or down. The p95 pen draws on its own pane beneath, under every strip, behind a click on each row, or not at all, as the Response time setting says. Hovering a cell reads the hour: uptime, runs, p95. Readers pick the range from the Monitors head; 90 d is offered where the plan keeps rollups that long (Pro and Business).

Two switches on the Page tab decide how much of this shows: Show uptime (the figures and the 30 d number) and Show uptime graph (the strips and runways under the rows). A page that shows uptime but no chart is a plain list of words and figures, which some people prefer. The LAYOUT plate on the Look tab holds the rest: Response time, Figures, the headline band, and whether each group is a card of its own.

Groups

Rows draw in one list until you name a group. The Monitors tab takes any number of them, "Storefront" or "Mail" say, and each row picks the one it sits under; rows with none stay at the top. If the zone is already split into sub-zones, switch Groups to Mirror sub-zones and the page follows them instead. A group on the page carries the worst lamp of its rows and their count, so a reader sees at once which part of the service has the trouble.

Incidents: the ones the checks raise, and the ones you write

An automatic incident is an open episode on one of the page's rows: the moment a down or a not-valid certificate is confirmed, it is on the page with when it was raised; when someone acknowledges the alert, "Acked" and the time join it; when it clears, "Cleared" and how long it lasted. Nobody can edit one: what it says is what the monitors saw. A row that is down also says where it was seen from, "from Frankfurt and Sydney, 2 of 3", or "from inside" when a Beacon in your own network saw it; the Beacon's name never leaves the app.

A written incident is yours. The INCIDENTS plate, on the Incidents tab, opens one with a title, an impact (minor, major, critical), the rows it touches and a first note; from then on each step, Investigating, Identified, Monitoring, Resolved, is an update with a time and your words, and once it is resolved you can write the postmortem under it. While one is open its title is the page's headline, its rows wear an "Incident" tag that leads to the incident's own page, and every step is mailed to the subscribers. The page lists the last 30 days; /status/<slug>/history lists twelve months of both kinds, by month. Members can write incidents; the rest of the page is an admin's.

A deploy pipeline or a runbook can do the same through the incident door: one POST /api/incident/<token> with title, status, impact, message and row (a public name, repeated), as a query string or a JSON body. A new title opens an incident; the same title again, while it is open, adds the update; status=resolved closes it. The token is on the INCIDENTS plate behind Reveal, and Rotate kills the old line at once.

Maintenance

Planned maintenance comes from the maintenance windows you schedule on the zone or a monitor. A window in the future is listed with its start on its own clock, its length and its repeat ("Sundays", "every day"); while one runs, the page's headline reads Planned maintenance in progress and the rows under it go unlit rather than red. Maintenance now, from a page's ⋯ menu, is a window too, and it shows as "until further notice". Subscribers are mailed a day before a window and again when it starts, once per occurrence of a repeat; the SUBSCRIBERS plate has the switch.

Subscribers, feed, JSON and badges

Anyone can subscribe from the foot of the page with an email address. It is double opt-in: a confirmation mail first, then a message when something on the page goes down and another when it comes back, one for every step of a written incident, and the maintenance notices, each with an unsubscribe link. The page owner never sees the addresses in bulk; they are a tally on the editor.

Every public page serves two machine-readable views as well. /status/<slug>/feed.atom is an Atom feed of its incidents of both kinds, newest first, each entry moving with its latest update. /status/<slug>/api/v2/summary.json is the page in the shape Statuspage made standard: the overall indicator, your rows as components with your groups as component groups, the open incidents with their updates, and the windows as scheduled maintenances. Any tool that reads status pages reads it, hostnag's own vendor status monitor included: paste your page's address into one and it is recognised.

Every page and every row has a badge: /status/<slug>/badge.svg reads status: all normal, status: 2 down or status: degraded, and /status/<slug>/m/<monitor id>/badge.svg reads a row's own word, up 99.98% or expires in 11 d. Both are SVGs cached a minute, made for a README, a wiki or an internal portal.

Look, links, privacy, and the domain

Your logo goes on the page on every plan: the page's own, or the org's when the page has none. The HEADER plate decides what stands beside it on the strip: Subscribe, History and Feed doors and up to six buttons of your own (a label and an address each), every one with a switch and a place: Strip keeps it on the bar, More puts it behind one MORE button that opens a side sheet, which appears only when something is behind it. Two or three on the strip and the rest behind MORE reads best on a phone. The APPEARANCE plate picks a light or dark enamel and one accent colour, which paints the band along the top, the buttons and the links; LINKS makes the logo and the title lead to your site, adds a "Contact support" link and a line of your own at the foot. The "Monitored by hostnag" line is on by default and can be switched off on Pro and Business; a downgrade puts it back without touching the page.

PRIVACY has two switches. Keep out of search engines asks them to leave the page out of their results. A passphrase, on Pro and Business, makes the page private: a reader sees the title and a field and nothing else until they give it, once per browser, and the badges, the feed and the JSON answer 404 while it is set. A passphrase already set stays in force whatever the plan, so a downgrade never opens a page by accident.

The address is hostnag.com/status/<slug> today. A custom domain, status.yourcompany.com pointed at hostnag with one CNAME, is not built yet. Until it is, a link from your footer or a redirect on your own domain does the job.