I'm amazed Microslop let us keep GitHub this long. Probably because they're training AI on it? To have a direct line to developers? I don't see why else they would've bothered with something that was so anti everything they stood for
What does Microsoft stand for?
GitHub appears to be struggling with measly three nines availability
211–220 of 255 posts
Re: GitHub appears to be struggling with measly three nines availability
#212Re: GitHub appears to be struggling with measly three nines availability
#213Earlier quoted context omitted.
Public service announcement You can pin actions versions to their hash. Some might say this is a best practice for now. It looks like this, where the comment says where the hash is supposed to point. Old --> uses: actions/checkout@v4 New --> uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4 There is a tool to sweep through your repo and automate this: https://github.com/mheap/pin-github-action
My preferred tool to solve these issues is called 'gitlab'
GitLab's `include` feature has the same concern. They do offer an integrity check, but it's not any more capable than hash pinning to a commit.
Fundamentally, if you offer a way to extend your product with externally-provided components, and you can't control the external publishers, then you've left the door open to 'these issues'.
Re: GitHub appears to be struggling with measly three nines availability
#214Re: GitHub appears to be struggling with measly three nines availability
#215It's wild because they are one of the most used properties on earth and their uptime is actually incredible.
Define incredible. https://mrshu.github.io/github-statuses/ Overall uptime is 90% (single nine), and the best individual service at 99.8% (two nines). The core git functionality itself is at 98.98%, which works out to being down roughly a full business day each month.
Re: GitHub appears to be struggling with measly three nines availability
#216Our security scanning runs on GitHub Actions — every PR gets checked before merge. When GitHub goes down, the security gate goes down with it. PRs pile up, devs get impatient, start merging without waiting for checks. That's exactly when bad code gets through. And they keep throwing engineers at Copilot while the stuff that CI/CD actually depends on keeps falling over.
Do you have one or more public examples of this?
Re: GitHub appears to be struggling with measly three nines availability
#217Earlier quoted context omitted.
Define incredible. https://mrshu.github.io/github-statuses/ Overall uptime is 90% (single nine), and the best individual service at 99.8% (two nines). The core git functionality itself is at 98.98%, which works out to being down roughly a full business day each month.
Not bad
Could be worse?
Re: GitHub appears to be struggling with measly three nines availability
#218GitHub is in a tough spot. From what I've heard they've been ordered to move everything to Azure from their long standing dataceners. That is bound to cause issues. Then on top of that they are using AI coders for infra changes (supposedly) which will also add issues. And then on top of all that, their traffic is probably skyrocketing like mad because of everyone else using AI coders. Look at popular projects -- a fe…
> Look at popular projects -- a few minutes after an issue is filed they have sometimes 10+ patches submitted. All generating PRs and forks and all the things. I think this is a really important point that is getting overlooked in most conversations about GitHub's reliability lately. GitHub was not designed or architected for a world where millions of AI coding agents can trivially generate huge volumes of commits an…
But GitHub karma botting is a thing now.
Remember those elitist ppl who removed answers on stackoverflow coz their answer is better with 90000 answers?
Yup, now they are on GitHub farming karma with bots.
Re: GitHub appears to be struggling with measly three nines availability
#219Re: GitHub appears to be struggling with measly three nines availability
#220Earlier quoted context omitted.
Not bad
At the risk of going recursive, how do you define not bad? Could be worse?
I am mostly going off of overall usage vs downtime.