Hacker News Reader

Comment by hx8 | Hacker News Reader

> We say something like:

> GitHub Actions: 12 hours affected in the last 30 days (98.31% uptime).

This is trying to shine the most favorable possible light onto a deteriorating situation. It doesn't take away from the fact that most businesses have measurable missed revenue in downtime. Customers that shop somewhere else, ads that were never severed, leads that grew a little colder. 12 hours of downed GitHub results in millions of dollars of lost developer productivity that was externalized by Microsoft to other companies.

We shouldn't be trying to spin downtime as "just a few hours a month." Those hours cost real dollars.

View on HN

I don’t see why you think “12 hours affected in the last 30 days (98.31% uptime)”

Is trying to spin anything. It’s making easier to see the impact over the last 30 days. I agree with the article

One thing I would like to see is how many of those hours are during normal business hours in my country.

Not all hours are created equal when it comes to downtime and my intuition is that most of these 12 landed within my working hours.

In terms of impact that then might mean they were down for 7.5% of the time I needed them, or had business hours uptime of 92.5% which is… both not very good and very disruptive.

On the other hand, downtime at 4AM would be much less impactful even if it happened every day and added up to more overall downtime.

> they were down for 7.5% of the time I needed them, or had business hours uptime of 92.5%

You can obviously compute this for a particular customer, but being a global service, it's pretty much guaranteed that someone somewhere experienced the worse of those numbers

You can compute them for the average. In other words, the total customer impact is the number of business-hours of downtime across all customers divided by the total number of business hours of all customers.

This is important because it's quite possible that the downtime is biased toward the times they have the most active users.

Big systems worth their salt already do this as weighted uptime, considering request successes / total requests rather than wall clock uptime as internal SLOs. But these numbers aren't really ever published because it gives away information about your customer base.

https://cloud.google.com/blog/products/gcp/available-or-not-...

"Failed customer interactions" - if you have a way to actually see requests before they hit your datacenter, e.g. some async third party client libraries.

On this topic, as a service operator, it's really nice when you also own your SDKs, and have client-side telemetry about failed requests. Gives you a much clearer picture of end-to-end reliability (at least for the subset of customers who opt-in to telemetry)

Favorable spin? The article's point is that "12 hours a month" makes the cost very obvious, and I agree with the article.

98% sounds like "nb, almost a perfect score". 12 hours sounds like "wow I lost a whole day this month", way worse.

Then again if you’re a business relying on GitHub enterprise you have an SLA and you can and WILL charge GitHub for failing their SLA. Usually there’s a real measurable dollar value tied to that SLA per dollar and it’s not cheap. What surprises me in particular is that the global API and the GitHub EE API are the same which is a big no no. This is even more surprising given the fact that paying GitHub customers are clearly the minority both in numbers and code velocity. My assumption would be that GitHub is keeping EE up and the rest of free or pro users just have to suck it up. If that’s not even the case then it’s only a matter of very short time until GitHub will see businesses leave to more reliable competitors

SLAs don't relly get you meaningful money back, they give you a way to get out of long contracts early and switch to a better vendor.

> We shouldn't be trying to spin downtime as "just a few hours a month." Those hours cost real dollars.

They're also completely irrelevant, you as a customer of a service that is down can lose the same amount of money in a 5 minutes outage or 30 days outage, if you were only relying on this service for one operation that took 1 second and had to happen during the time where the outage happened.

Depending on the service in question, no amount of downtime is acceptable, however unrealistic this is.

> ads that were never severed

A lack of ads is an argument for more downtime.

Reply on news.ycombinator.com