Watchrr: what a green status page doesn't tell you
Watchrr is meant to become a trading-floor dashboard for the internet. The first instrument on the board is outage monitoring — and the hardest part turned out to be deciding which sources to believe.
Stand on a trading floor and you can read the state of a market in a glance. A wall of numbers, updating live, and everyone in the room knows what is happening at the same moment.
There is nothing like that for the internet. Outages, model releases, game patches, what is climbing on search, which platform is having a bad afternoon — all of it is real, all of it matters to somebody, and all of it is scattered across a hundred places that do not talk to each other. You find out something broke when your feed fills with people complaining.
That is what Watchrr is aimed at: a source of truth that keeps tabs on the digital world, so people can see what is going on without assembling it themselves. The whole board, in one place.
The first instrument on that board is outage monitoring, because it is the one people need most urgently and the one nobody does well. Watchrr tracks 228 services across 15 categories — gaming, streaming, cloud, AI, payments, app stores, developer tools — refreshed every 10 to 15 minutes.
And building that first instrument taught me something I did not expect. The hard part is not polling. It is deciding what to believe — because the sources that are supposed to tell you the truth are frequently the ones lying to you, and usually not on purpose.
A 200 is not a status page
Most large services publish a JSON feed through Atlassian Statuspage. You fetch
it, you read status.indicator, you are done. That works until it doesn't.
Lyft deleted its Statuspage account. The URL we had pointed at —
lyft.statuspage.io — still resolves and still returns HTTP 200, because
Atlassian serves its own marketing page there. Nothing about the request looks
like a failure. It has a status code in the 200s, it has a body, it has headers.
It only falls over at JSON.parse.
The obvious fix is to point at lyft.com instead and check whether it loads.
That fix is worse than the bug. Lyft's marketing site is served by different
infrastructure than Lyft's ride dispatch. A 200 from the homepage would let us
paint Lyft green while telling you exactly nothing about whether anyone can get
a car. We would have replaced "no data" with "confidently wrong", which is the
worse of the two.
So Watchrr leaves it broken on purpose. The staleness guard notices that nothing has parsed in a while and renders Lyft as not reporting. That is an unsatisfying thing to show a user. It is also the only honest thing we can say.
Some status pages can't be read at all
A surprising number of "official status pages" are not machine-readable. Paramount+, EA's help site, Activision support, Rockstar support — these are JavaScript-rendered single-page apps, or they sit behind a Cloudflare challenge. From an edge function with no browser, there is nothing to parse.
Those services get a deliberately weaker check: a HEAD request to the primary
domain. If it answers 2xx or 3xx we call it operational, otherwise partial outage.
That is genuinely worse monitoring, and Watchrr labels it as limited rather than pretending it is equivalent. The alternative — running a headless browser against a few dozen status pages every ten minutes — is a real option, and one day it may be worth the cost. It is not worth it yet.
Polling politely, and the bug that created
Two hundred and twenty-eight services on a ten-minute cycle is a lot of requests
pointed at other people's infrastructure. The fix is old and boring: conditional
GETs. Store each source's ETag and Last-Modified, send them back as
If-None-Match and If-Modified-Since, and let the server answer 304 Not
Modified when nothing has changed.
A 304 has no body. Nothing to download, nothing to parse, nothing to write. On a normal day, when almost nothing is broken, the overwhelming majority of polls cost almost nothing — for us and for them.
Then this happened.
A 304 means nothing changed, so the early code returned immediately and skipped
the write path entirely. Which is correct for status — and completely wrong for
last_checked_at. A service whose upstream was perfectly stable never had its
timestamp advanced, so its "last checked" froze at whenever its status last
changed.
DigitalOcean was the one that gave it away: zero consecutive failures, a successful 304 a few minutes earlier, and a database row claiming it had not been checked in two days. The monitoring was working. The monitoring's own report of itself was broken.
The fix is one line in concept — advance the timestamp on a 304, because a 304 is a successful check — but it comes with a trap.
The trap in the fix
Watchrr keeps a set of service IDs it polled this run. That set gates a cleanup step: any incident that no longer appears in a service's upstream feed gets deleted, because it has been resolved.
The instinct when fixing the timestamp bug is to add the 304'd service to that set. It was polled, after all.
Do that and you delete live incidents. A 304 carries no body, which means it carries no incident list. An empty incident list is not the same as "no incidents" — it is "no information". The cleanup would read that absence as resolution and wipe out every ongoing incident for every service whose feed happened to be unchanged that minute.
So the 304 branch refreshes exactly one field and touches nothing else, on a throttled interval so it stays cheap — at worst one row per service per 30 minutes rather than one per service per poll.
Not just status pages
Official feeds only tell you what a company is willing to admit, usually after someone has confirmed it internally. So Watchrr also pulls from sources that do not need anyone's permission:
- Cloudflare Radar — traffic patterns, protocol mix, attack vectors
- IODA — internet outage detection at the network level
- NetBlocks — connectivity disruption reporting
These feed the Internet Pulse score on the dashboard, and they are how you notice that something is wrong before a status page catches up.
Where it goes next
Watchlists, saved favourites, team monitoring, and a public API are the next things on the list. No dates — they will land when they are good.
But the direction matters more than the queue. Outages are one instrument. The board it belongs on also has game developments, major tech news, what is climbing on search engines, AI announcements and model releases — the things that make up the state of the digital world on any given day, in one place, updating live.
Everything above is why that is harder than it sounds. A dashboard is only worth looking at if you can trust what it says, and the last few thousand words are what "trustworthy" costs on a single instrument. Doing it for the rest of them is the actual work.
Watchrr is watching the digital world. Right now it watches whether the digital world is up.
If you want to see it working, Watchrr is live — no account needed. And if you catch it reporting something wrong, there is a bug reporter on every page of this site. Reports that turn into fixes get credited by name.
