101–110 of 131 posts
Earlier quoted context omitted.
Data comes from the official status page. It may be more a marketing/communication page than an observability page (especially before selling)
The status page was often down when GH was down, back in the days.
Earlier quoted context omitted.
I think reasonable people can disagree on this. From the point of view of an individual developer, it may be "fraction of tasks affected by downtime" - which would lie between the average and the aggregate, as many tasks use multiple (but not all) features. But if you take the point of view of a customer, it might not matter as much 'which' part is broken. To use a bad analogy, if my car is in the shop 10% of the tim…
Or if your kettle is not working the house is considered not working?
Earlier quoted context omitted.
I think reasonable people can disagree on this. From the point of view of an individual developer, it may be "fraction of tasks affected by downtime" - which would lie between the average and the aggregate, as many tasks use multiple (but not all) features. But if you take the point of view of a customer, it might not matter as much 'which' part is broken. To use a bad analogy, if my car is in the shop 10% of the tim…
A better analogy is if one bulb in the right rear brake light group is burnt out. Technically the car is broken. But realistically you will be able to do all the things you want to do unless the thing you want to do is measure that all the bulbs in your brake lights are working.
One bulb in the cluster going out is like a single server at GitHub going down, not a whole service.
I got Claude to make me the exact same graph a few weeks ago! I had hypothesized that we'd see a sharp drop off, instead what I found (as this project also shows) is a rather messy average trend of outages that has been going on for some time. The graph being all nice before the Microsoft acquisition is a fun narrative, until you realize that some products (like actions, announced on October 16th, 2018) didn't exist…
It feels like they launched actions and it quickly turned out to be an operations and availability nightmare. Since then, they've been firefighting and now the problems have spread to previously stable things like issues and PRs
Webhook doesn't fire, nothing errors out, and you find out when someone asks why staging hasn't moved in two days.
Earlier quoted context omitted.
The same philosophy would suggest that running some other command immediately following a particular (successful) git command is fine; it is composing relatively simple programs into a greater system. Other than the common security pitfalls of the former, said philosophy has no issue with using (for example) Jenkins instead of Actions.
[flagged]
Historical * https://www.merriam-webster.com/grammar/everything-youve-eve...
Earlier quoted context omitted.
The status page was often down when GH was down, back in the days.
Aha we need a status page of status page.
Even better IMO is this status page: https://mrshu.github.io/github-statuses/ "The Missing GitHub Status Page" with overall aggregate percentages. Currently at 90.84% over the last 90 days. It was at 90.00% a couple days ago.
Well, I mean, I guess that's fair really. How long has github been around? Surely it's got five weeks of paid time off by now...
Earlier quoted context omitted.
Data comes from the official status page. It may be more a marketing/communication page than an observability page (especially before selling)
The status page was often down when GH was down, back in the days.
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.