Live data from Hacker News

Days since last GitHub incident

github-incidents.pages.dev

61–70 of 142 posts

Re: Days since last GitHub incident

#63
post #10
post #5

[flagged]

because Microsoft are known for listening to their customers? this trivial bug fix took more than a year to be merged: https://github.com/actions/runner/pull/3157 that bug likely ended up costing customers millions

Discussed entertainingly here by ThePrimeTimeagen: https://youtu.be/E3_95BZYIVs?si=IY-iT1eyXKnVvpTS

Re: Days since last GitHub incident

#65

This is a bit... low-effort, isn't it? I'd at least expect a video of an exasperated Github user walking up to the '# days since the last GitHub incident' board, sliding out the '1' or '2' card, and replacing it with a '0'. I mean, that joke is as old as the universe (heck, in the brief period that I worked in an office, decades ago, I had a "# days since the last person asked a stupid question" sign to enact the exa…

Very low effort. Couldn’t read the text on my iPhone without zooming in. I nearly mistook it for a blank page!

Re: Days since last GitHub incident

#67

I've been getting some weird cryptocurrency spam notifications on GitHub and they can't be cleared for some reason. Blue dot is gonna be there forever apparently. Some users made an issue out of it but nobody cared to fix it.

Same happened to me. You can clear it via the CLI, hilariously.

```

gh api notifications\?all=true | jq -r 'map(select(.unread) | .id)[]' | xargs -L1 sh -c 'gh api -X PATCH notifications/threads/$0'

```

Re: Days since last GitHub incident

#68

I've been getting some weird cryptocurrency spam notifications on GitHub and they can't be cleared for some reason. Blue dot is gonna be there forever apparently. Some users made an issue out of it but nobody cared to fix it.

Had the same issue that the blue dot won’t disappear. I was able to clear the dot with:

gh api notifications -X PUT -F last_read_at=2025-10-06T00:00:00Z

Just change the date to today. I also got that line from a gh issue somewhere - maybe it was the same issue that you’re referring to.

Re: Days since last GitHub incident

#69
post #25

This is why I keep encouraging folks to a) have a mirror & b) make sure their tools automatically pick up the mirrors. I recently got mirror support upstreamed into Nixpkgs for fetchdarcs & fetchpijul which actually work on my just-alpha-released pinning tool, Nixtamal https://darcs.toastal.in.th/nixtamal/trunk/README.rst >, for just this sort of thing.

I envy you. Most of us struggle to get the resources to make our actual customer facing applications resilient, let alone our build pipeline.

Building your software usually involves getting dependencies, & those dependencies are, hopefully, in more than one location—which includes a cronjob to a bare repo, or Alice’s fork on another repo that at least has the latest tags. It should be trivial to point to these as mirrors for the cases where any forge/repository, even the ones held by megacorporations, inevitably go down. Even Nixpkgs itself, while not maintaining their own official mirrors, are mirrored by TUNA. Backups are an important strategy, & the source code should also be a part of that.

Re: Days since last GitHub incident

#70

At this point, is there any downside to switching to GitLab?

If escaping downtime is your goal, then you should aim for a service with less downtime than Github. (they're roughly the same, with Gitlab having a slightly higher percentage of "major" outages)
Post reply on HN