GitHub is having trouble counting things
chuckgreenman
74 points
56 comments
September 16, 2026
Related Discussions
Found 5 related stories in 72.9ms across 6,833 title embeddings via pgvector HNSW
- Incident with Github.com kevcampb · 698 pts · August 17, 2026 · 60% similar
- GitHub Has an Availability Problem. Is It Time to Look Elsewhere? dhruv3006 · 63 pts · August 17, 2026 · 59% similar
- Incident with Github.com [resolved] SpyCoder77 · 536 pts · August 17, 2026 · 59% similar
- GitHub Outage rumblefrog · 13 pts · July 20, 2026 · 58% similar
- GitHub is the wrong shape for this new world emschwartz · 52 pts · July 29, 2026 · 56% similar
Discussion Highlights (20 comments)
hanspagel
I think they struggle with two things 1) counting
mickael-kerjean
This got to be the extinguish phase from the EEE Microsoft playbook. Prior acquisition, Github was very liked and very focus, then Microsoft happened in their embrace phase, telling us EEE was something of the past. While trying to show good faith they extended the platform and this is now the very last phase
apocalyptic0n3
Calling this "severe" feels overblown. It's a UI mismatch likely caused by using multiple caches that are out of sync. I feel like every engineer on this site has encountered this exact bug at one point or another. It's an easy one to run into, especially in bigger orgs.
cedws
There's tonnes of UI bugs. A more severe one I've experienced is that my approved PRs have been shown as still waiting on review, leading some of them to be delayed by weeks.
datadrivenangel
Dirty reads is a classic symptom of scaling poorly. Eventually consistent database writes are fine, but it's a bad look if a user takes an action and then doesn't see the results of their action.
huurtehoog
The fact that there's so much indirection between what happens in the registers and memory in the machine, the underlying reality being modeled by software, and the information displayed semantically to the users, is a travesty. Software could be so much simpler and more reliable. There's so much bloat that is necessary to solve problems created by bloat. I hope we find our way out of this mess sooner rather than later. I'd hate for entire generations to suffer the current state of software whereas the theoretical understanding necessary to make things better was produced very early in the history of programmable computers.
zX41ZdbW
Some of the oldest PRs could no longer be found. For example, when I decided to continue my eight-year-old PR https://github.com/ClickHouse/ClickHouse/pull/104948 , I couldn't see it - neither in search nor while navigating through pages. Direct links still work.
whalesalad
rails + russian doll style caching + large engineering team + azure as a platform = recipe for this exact problem.
booi
Press "Next"
nubinetwork
My phone consistently says that I have one more update than they'll actually let me download... what that one phantom app is, I'll never know...
Rooster61
> Really curious as to what’s going on over there, if you’ve got any insight let me know! Microsoft. That's the answer. Microsoft is happening over there.
mococa
AI will solve this
disko
I have got an insight alright. Microsoft took it over.
nxc18
GitHub, including Enterprise (so not just Azure’s fault), has become unreliable, low quality software. I say unreliable because I cannot rely on it to accurately do what it claims to do. I cannot trust any number. I cannot trust that actions I invoke will actually happen. I cannot trust that taking action will not have mysterious side effects (e.g. re-opening an issue my boss’s boss closed in 2017 without explanation). I think I trust the underlying git infra but at this point I’m not sure why I do. I say low quality because it is extremely slow at random moments, gets into broken inconsistent UI states, has baffling UX choices that make it harder to navigate than it should be (particularly with new UIs), and overall just doesn’t have the fit and finish we should expect from software in 1996 - or 2026, or literally any time in between.
stabbles
The reason is that their primary source of truth (traditional database) and their search index (elasticsearch) are out of sync. The issues/pulls pages used to be showing the data from the primary data source, and then they changed it so everything is search, including the basic props is:pr and state:open.
Droobfest
I was having the problem yesterday that the GitHub API sometimes simply doesn't list an in progress workflow run in the output when I specifically filter for it: "api.github.com/repos/{owner}/{repo}/actions/runs?status=in_progress" -> outputs 3 workflow runs 5 seconds later -> outputs 2 workflow runs 5 seconds later -> outputs same 3 workflow runs again Apparently they make no guarantees of any type of consistency or continuity in output, which has the side effect of also making it completely useless.
thetnaingnyc
GitHub's downfall must be studied. At the same time as all of these reliability issues, they've been introducing a variety of small UI updates that don't make any meaningful updates either...
stack_framer
The same counting problem exists with GitHub issues. I notice this every time I close an issue, and the count of open issues is still one higher than the actual number (until I reload the page).
bob1029
This appears to be a security problem in some contexts. I've been able to see issue counts for repositories that I have not been granted access to yet (the view with the invite accept button). I can't actually get to the issues but I can see how many there are.
meerita
I know this pain because, right now, I have zero PRs opens, yet the PR tab is always saying I have 1. It's plainly stupid.