I designed for a rare GitHub outage. It happens every three days.

I built a thing that answers one question: is GitHub down. It reads GitHub’s official status feed and shows the answer on a slot machine. You pull the lever, the reels spin, you get told.

The part I actually cared about is what happens during an outage. A shared round opens. Everyone on the page collects the same pool, and when GitHub recovers, everyone who was present can claim a numbered ticket for that outage. Seat 392 of 1,438. There is no way to get one afterwards.

The whole design rests on one assumption: that a big GitHub outage is rare. A ticket you cannot get later is only worth having if later is most of the time.

So I checked, and I had it backwards.

What GitHub’s own feed says

I pulled GitHub’s incident history on 18 August 2026. The API returns the last 50 incidents, which for GitHub covers 17 June to 18 August: 62 days.

• 50 incidents in 62 days, and that is a floor rather than a count, because 50 is where the API stops
• 19 of them were major or critical: 11 major, 8 critical
• Those 19 add up to 50 hours and 45 minutes of incident time
• Which is one card-eligible outage every 3.3 days on average

The three longest were 642, 558 and 456 minutes. The 456-minute one was yesterday.

My read, and it is a read rather than a finding: two months is a short window and I do not know whether this summer is normal for GitHub. But the gap between what I assumed and what the feed says is too wide to be sampling noise. I built a collectible around an event I thought was exceptional, and over the window I can see, it is a Tuesday.

I have made this mistake before in a different costume: trusting a green check because it was green rather than because I knew what it was checking. This time it was worse, because the assumption was never stated. It was just load-bearing.

The bar was already the interesting decision

There is a detail in the build that I made for one reason and that turns out to matter for another.

The machine reports any degradation as down, because that is honest to the status page and it is what someone came to find out. But a ticket only mints on major or critical. Two different thresholds on purpose.

I did that because GitHub nearly always has something degraded or a maintenance notice open, and minting on that bar would have produced tickets constantly. The numbers say the same thing louder than I expected: 29 of the 50 were minor. Had I used one threshold, the scarce thing would have arrived several times a week and meant nothing.

The strict bar was defensive. It turns out to be the only reason the mechanic has any scarcity left at all.

What I cannot do, and why it bothers me

Yesterday’s critical incident lasted 456 minutes. It cannot be outage #1.

Nothing records an outage except a cron job polling every 60 seconds, and that job was not scheduled yet. An outage that happens before the poller runs is not recoverable: there is no start time I trust, and more to the point there is no record of who was there, so there is nobody to give a ticket to.

I knew this when I built it, which is why the recording half shipped before anything visible did. It is still annoying to watch a perfectly good 7-hour outage go past uncounted.

Numbering starts at 1 with the next one.

Next

The mechanic has never run. On the evidence above, that will not last: if the last 62 days are anything to go by, it fires within the week.

What I want to see is whether the shared counter does what I think it does. My guess is that watching a number climb with a few hundred other people is a different experience from refreshing a status page alone, but that is a designer’s guess about a room that has never had anybody in it.

If you have built something whose whole premise depended on an assumption you never checked, I would like to hear how that went. Mine survived, but only because a decision I made for a different reason happened to catch it.