Our status pages could tell your customers something was down. What they couldn't do was say what was going on or when it'd be fixed, which is most of the reason you'd put one up.

And if you wanted to tell people about something our checks can't see, the page carried on underneath you saying all systems operational. A few of you pointed that out. You were right, and it's fixed.

You write the incident now

You can publish an incident from your status page: a title, how bad it is, and then updates as you learn more. Investigating, identified, monitoring, resolved.

It belongs to the page rather than to one monitor, so you can post about things we'd never detect ourselves, like a payment provider having a bad morning. One incident covers as many of your services as you like and still reads as one thing rather than six. If six monitors dropped because a single server died, you can pull those alerts into it so your customers get one story.

While an incident is open the page won't claim everything is fine.

Subscribers get an email on each update rather than only when it's over, and every incident keeps a permanent link, which is what you want when someone asks in support two weeks later.

Slow isn't down

A site taking 14 seconds to answer still passes every check we run, so it sat there in green next to one answering in 90ms while its users had a miserable time.

You can now put a threshold on a monitor and we'll show it amber instead. It goes off either the last check or a rolling p95, and wants a few in a row before it changes anything, so one slow response won't flip your page back and forth.

A slow check still counts as up. That was the bit we were most careful about. Switching this on won't move your uptime number by a decimal, historically or from here, so your SLA means what it meant yesterday. Time spent slow gets reported separately, next to it. Slow alerts are opt-in per contact as well, so nobody starts getting woken up about latency because someone else set a threshold. It's off unless you turn it on.

What the failure looked like

When a check fails we now keep what we saw: the status code, the headers worth keeping, the first few KB of the body, and where the time went. DNS, connecting, the TLS handshake, waiting on your server.

All of that is per location, so instead of "down for four minutes" you can see Cloudflare handing Los Angeles a 522 while Helsinki got a clean 200. A slow handshake looks nothing like a slow server, which is usually the first thing you want to know.

We keep it for 30 days, and we don't store credentials: headers go through an allow-list, and we strip out anything you've set as a request header.

Like last time, most of this came from someone sending us a message. Please keep doing that! 🙌

Hey Sumo-lings,

Last time I wrote here, it was to admit we'd been waking you up over sites that were fine, and to explain the fix: a fault now has to be seen by a majority of our checking locations and still be broken a few seconds later before your phone goes off.

That's a thing of the past now, but we’ve gone further in that same theme, with some exciting announcements for today!

See what each location saw

Open any monitor and there's a new "Checked from" panel. When a check goes to a vote, you get what each location saw, probe by probe: Helsinki 143ms, Johannesburg 402ms, Los Angeles a 503 — twice.

The interesting rows are the ones where we didn't call you. A check marked Disputed now says so plainly: the locations disagreed, only one of three saw a fault, we didn't alert you, and it doesn't count against your uptime. Same for a blip that had already vanished by the re-check.

Those are judgement calls you were trusting us to make in the dark. Now you can audit them.

One detail we were careful about: a location that never answered reads as "No answer", never as agreement. Silence isn't a vote, and counting it as one is exactly the mistake this whole system exists to prevent.

Badges and an embeddable widget

If you've got uptime worth showing, show it. Every public status page now gives you an SVG badge for your README or your footer — uptime over anything from 7 days to a year, current status, or last response time — plus a live status widget you can drop into your own site in an iframe.

The copy-paste snippets (Markdown, HTML, BBCode, iframe, JSON) are in the status page editor. The preview there is the real badge, not a mock-up of one.

They're only published for pages that are public and have no password. A password gate exists to withhold exactly what a badge would announce, and a badge has no way to ask for a password.

Your status page, your timeframe

Status pages were locked to 90 days. Now you pick: 7, 30, 60, 90, 180 days or a full year — and you can measure the headline uptime figure over a different window than the bars cover, so a page can show a year of history and still quote 30-day uptime.

A year doesn't render as 365 unreadable slivers on a phone. It folds into columns covering a few days each, and hovering one tells you the span it represents. Days before your page existed stay blank rather than counting as downtime you never had.

Most of what's here started as a support message from one of you. Keep them coming — they're the best signal we get.

— Chris

Some of you got woken up over the past few weeks for sites that were fine. You'd open the laptop at 2am, load the page, and there it was, up. After that happens three or four times you stop trusting the alerts, and an alert you don't trust is worth nothing.

What we assumed, and what the data said

Moonitor checks your site from Helsinki. Before it opens an incident it asks a second machine in Los Angeles to look too. The idea is that if our Helsinki box is having a bad day, Los Angeles disagrees and we keep quiet.

So we assumed Los Angeles had gone flaky and was calling things down that weren't.

It hadn't. We pulled the records, and every incident from the previous week had been independently confirmed by Los Angeles. The box was healthy and barely working. It wasn't inventing anything.

The problem was ours, and it was subtler than a broken box. Both machines were checking at the same instant. So when a site hiccuped for a second, both of them genuinely saw the hiccup, agreed with each other, and we treated that agreement as proof of an outage.

On top of that, we opened an incident on the very first failed check. One unlucky sample was enough to wake you up.

One customer's site made this painfully obvious. It sits behind a web server that returns an error on roughly one request in five, at random. We tested from three continents and got the same thing everywhere.

What changed

A fault now has to clear two bars before we'll alert you.

The first is agreement. A majority of the checking locations that answer have to see the same thing. One machine's opinion isn't enough.

The second is the one that actually matters: it has to still be broken a few seconds later. When a check fails we wait, then check again from every location. Site's back? It was a blip. We log it and leave you alone. Still down? You get the alert.

The same rule runs in reverse now, which fixes a separate complaint we've had: a site that flickers back up for one check no longer gets marked recovered, then down again ten minutes later. No more alert storms out of one wobbly server.

A third continent

We've added a checking location in Johannesburg, alongside Helsinki and Los Angeles. Different provider, different network.

Part of that is tie-breaking. With two locations they could only agree or deadlock, and a deadlock meant we froze and did nothing at all. On one monitor that happened 23 times in a month, and we were blind to it the whole time. A third location settles the argument.

A fourth continent is being added at the moment.

Your uptime number stays honest

When the locations disagree, or when a fault vanishes on the second look, we record the check and show it in your history. It does not count against your uptime percentage. If we can't demonstrate a fault happened, we're not putting it on your report card.

Hey Sumo-lings,

Quick update on what we've been building. A lot of it came straight out of your emails and questions, so — genuinely — thank you.

We now double-check every outage multiple countries.

This is the one we're most proud of. The honest truth about uptime monitoring is that a lot of "downtime" alerts aren't downtime at all. A bad network route, a firewall that mistook our checker for a bot, one dodgy DNS answer — from a single location, every one of those looks exactly like your site being down. And you're the one who gets woken up for it.

So we stopped watching from a single location. Moonitor now checks from multiple countries, on separate networks and different continents. Before we open an incident, we re-run the failing check somewhere else entirely. If the second country can still reach you, we don't call it an outage, and we don't call you. It doesn't count against your uptime either — we're not going to dent your numbers over something we can't prove.

And it never works the other way. If one of our checkers goes unreachable, we still alert you. We'd rather send an alert we're unsure about than sit quietly on a real outage.

Behind Cloudflare? It just works now.

You can set custom request headers (including a browser user agent) and pick exactly which status codes count as healthy. If a WAF was challenging our checks and giving you phantom downtime, that's sorted.

DNS monitoring that actually catches changes (Team & Max)

We remember the last record we resolved and alert you the moment it moves — you don't have to tell us what to expect. Good for catching a hijack, or someone quietly re-pointing a record.

Status pages got a lot better

- Your own domain, with SSL set up automatically

- Your logo, your colours — proper theming

- White-label: switch off "Powered by Moonitor" entirely

- Your users can subscribe to updates by email

- Maintenance windows, so planned work doesn't page anyone

- SMS alerts

That's the lot for now. Keep the feedback coming — a good chunk of the above started life as a question in this very tab.

— Chris & the Moonitor team