I wrote a blog [1] last week about what we've been doing at Depot to work around GitHub's instability. I wrestled with how to present their downtime in a way that communicates its real impact to users, and I landed on a similar approach as the author. But I think even this doesn't state it strongly enough. Their uptime stat comes from their public status page, so it's conservative by definition. And it's important to remember that their downtime comes almost exclusively during business hours, when people are relying on the platform to get work done.

There are projects like The Missing GitHub Status Page [2] that attempt a more accurate reporting, but taking 98.31% for granted, I think the more impactful framing would be _a floor_ of 1.5 business days lost every month. At 22 business days per month, that can feel more like 7+% downtime.

[1] https://depot.dev/blog/github-actions-without-github

[2] https://mrshu.github.io/github-statuses/

You should be slightly careful about that.

I saw a User's Group presentation by a guy at Speakeasy, they had made a whole logistic system that looked a lot like a CRM manager but not for customers, for dealing with how flaky Covad was at the time. Covad only had to be less shitty than Qwest (who we called, "Qworst", because if you hadn't dealt with Covad, they were the worst) and they couldn't even manage that.

So if Covad promised to have some line work done by 10 am on Tuesday, the SE techs would get a reminder to verify in had been completed shortly after the deadline so they could call Covad before the customer noticed the install was behind schedule and ask why it hadn't been done by the deadline. Otherwise SE was telling people they'd have Internet in 4 business days and it would be more like 10 - on average.

Around the time Qworst became CenturyLink, Covad bought SpeakEasy, for a net loss of beauty in the world.