The Outage Ledger

I keep a ledger of outages. Not my own, which I track separately and which are more frequent than I would like. This one records the large ones: the days when a substantial fraction of the consumer internet stopped working at the same moment, for the same reason, in a way that made the evening news.

I started it in 2019 because I noticed I was arguing about decentralization from theory, and theory is cheap. The ledger is not a prediction. It is a record of things that already happened, which is a stronger form of evidence and a much harder one to argue with.

The shape of the failures

Strip the vendor names and the dates and there are four recurring classes.

Failure class	Typical blast radius	What kept working
Single cloud region degrades	Thousands of unrelated services at once	Anything hosted elsewhere, email between other hosts, local-first apps
CDN or edge config push	A wide slice of the web, simultaneously, within seconds	Origin servers reached directly, cached content, non-participating sites
BGP route withdrawal	One network's entire footprint, globally	Everything not routed through that network
Managed DNS provider under load	Every name delegated to that provider	Names on other providers, plus cached lookups until TTL expiry

The dates differ. The vendors differ. The shape does not. In each case a very large number of services failed together, not because they were related, but because they had quietly agreed to share a dependency, and none of them had counted it.

Correlation, not frequency

Here is the part where I have to argue against myself, because the naive version of my own thesis is wrong.

Distributed systems do not fail less often. Mine fails more often. I have measured both.

System	Availability, trailing 12 months	Outages	Households affected per outage
My self-hosted stack	99.92%	11	1
A major cloud region	roughly 99.99%	few	millions

The hyperscaler wins the uptime column and it is not close. Anyone selling you self-hosting on reliability grounds is selling you something. My VPS provider does unannounced maintenance. My NAS needed a power supply in March. My home connection has a monthly fifteen-minute personality.

The column that matters is the last one. My failures are uncorrelated with yours. When my mesh node goes down, your garage door still opens. When a shared dependency goes down, every household that quietly depended on it goes down in the same minute, and recovery is in someone else's hands while you refresh a status page. This is the whole argument, and it is a statement about correlation, not frequency. I have been imprecise about that before and I would rather be corrected by myself than by a reader.

The evening it stopped being abstract

During one of the ledger entries I happened to be at home with instrumentation running, which turned an inconvenience into a free experiment.

What failed: the garage door opener, which I documented in June as needing a foreign cloud to lift a door six feet. The thermostat's remote control, though the thermostat kept its schedule. Two streaming services. The doorbell.

What did not fail: the lights, which speak a local protocol. Email, because it federates and the other hosts were fine. The mesh node on the roof, which had never heard of the region in question. Every file on the sync mesh. The password vault, at a different provider on a different continent.

The split was not about which things were expensive or modern. It was about which things had to phone a building to do their job. That is the only variable that predicted survival, and I have not found a counterexample in seven years of entries.

What the ledger is actually for

Falsification. A thesis that only accumulates confirming evidence is not a thesis, it is a hobby.

So the ledger has a bearish threshold written into the front page, dated before the data comes in: if a full calendar year passes with no correlated, multi-service, greater-than-one-hour outage traceable to a shared dependency, I will mark it in the tracker and drag my confidence down accordingly. Consolidation would be getting more reliable, faster than it is getting more concentrated, and that is a world in which I am wrong about something important.

That year has not happened since I started counting. 2019 through 2025 each contain at least two qualifying entries. 2026 has one so far, and it is July.

I put 0.92 on at least one more qualifying entry before 2026-12-31. That is a lower number than the base rate would suggest, which reflects nothing except my discomfort at forecasting outages I would rather not have.

The practical advice is the least dramatic sentence I will write this month: for each service you rely on, write down the one building it has to reach. Where two services write down the same building, you do not have two services.