GitHub's Historic Uptime

I've seen so many times where Company A will complain that their vendors aren't accurate enough about uptime and how Company A notices first that their vendors are down, but then they themselves have a very laggy or inaccurate status page.

We want our vendors to be accurate to the minute on these, but many CTOs don't care to admit when they too have problems.

That being said, even when looking at the split uptimes, you'd have to do a very skewed weighting to achieve a number with more than one 9.

The problem here is the specification of what the system is. It's a bit unfair to call GH a single service, but it's how Microsoft sells it.

Not to go too out of my way to defend GH's uptime because it's obviously pretty patchy, but I think this is a bad analogy. Most customers won't have a hard reliability on every user-facing gh feature. Or to put it another way there's only going to be a tiny fraction of users who actually experienced something like the 90% uptime reported by the site. Most people are in practice are probably experienceing something like 97-98%.

GitHub Actions, on the other hand, is frequently used in the same workflows as the base GitHub product, so it's worth considering both separately and together, much like various Azure services, whereas I see no reason at all to consider an aggregate "Microsoft" downtime metric that includes GitHub, Azure, Office 365, Xbox Live, etc.

The most useful, metric, actually, is "downtimes for the various collections of GitHub services I regularly use together", but that would obviously require effort to collect the data myself.

What a weird takeaway

However, I don’t work on web apps. Maybe it’s better for the JavaScript folks. I hope to never write a line of js in my lifetime.

If they are using your data, you're still paying just not in cash.

As a former reliability engineer, I'm trying hard to remember back when we had multiple months in a row never reaching 100% uptime, and I can't. Yes, we've seen runs of painful months, but also runs of easy months without down time.

But let's talk root cause here, the cost of improving them here, is someone caring. This isn't simply a hard problem, it's a well understood hard problem that no one who makes decisions cares about. Which as a reliability engineer is an embarrassment. Uptime is one of those foundational aspects that you can build on top of. If you're not willing to invest in something as core as your code or service works. What are you even doing?

They’re a big enough corporation that we can have nuanced feelings about them. Simultaneously grateful for one part of what they do, and unsympathetic for the consequences of a different part of what they do.