GitHub's Profile Bug Hid 128 Merged PRs. Screen the API, Not the Squares

If you screen engineers by glancing at their GitHub profile, you have spent the last eleven weeks screening against a page GitHub itself says is broken. On October 15, 2026, a developer posted proof in GitHub's open incident thread that both the REST and GraphQL APIs confirmed 128 merged pull requests on their account. Their profile didn't show them. This piece covers what that incident means for sourcing developers on GitHub, and a five-minute API check that reads the record instead of the rendering.

A note on scope. An earlier post here asked whether commit authorship can be trusted. This one asks a different question: does the profile page show all of a developer's work? Right now the answer is no.

What did GitHub's profile incident actually hide?

It hid contribution graphs, achievement badges, and in at least one documented case 128 merged pull requests that GitHub's own APIs still returned. The incident is GitHub Community discussion #203416. A GitHub community manager opened it and labeled it "[Incident]" on July 29, 2026. It has 125 comments and 46 replies, and staff last updated it on September 23.

GitHub listed these symptoms:

• Profile layouts look different when you're signed in than when you're signed out
• Achievement badges don't show
• Contribution graphs don't accurately reflect commits

Staff said achievement delays had sometimes lasted days, and that GitHub doesn't "currently have a timeline to share on when this will be fixed." So the incident has been open for about 11 weeks with no fix date.

The October 15 post is the one that should worry sourcers. The developer used the authenticated GitHub CLI and wrote: "Both GitHub REST and GraphQL APIs independently confirmed 128 merged pull requests authored by my account." Another user got the prompt "You unlocked new Achievements with private contributions!" and then saw nothing render. Their conclusion: "the backend appears to know achievements have unlocked." The data was there. The page wasn't drawing it.

128

Why is the GitHub profile a rendering and not a record?

The profile page is a view drawn from data GitHub stores elsewhere, and that view drops things by design as well as by bug. The contribution graph is the grid of green squares on a profile, and it is drawn from contributionsCollection in GitHub's GraphQL API. When the drawing step fails, the data underneath can survive.

One developer saw "Something went wrong" where their graph should have been. They queried the API and found the data intact. If you've searched "github contribution graph not showing," that's the first thing to check: the graph may have broken while the history didn't.

The incident only adds to losses that are built in. Even on a good day, the graph leaves out a lot:

• Private work is hidden by default. It shows only if the developer opts in, and even then it appears as "anonymized counts (green squares without repository names)."
• Only default-branch commits count. Work on other branches doesn't show until it lands there.
• Fork-only work doesn't count until it's merged upstream.
• Reviews don't appear as squares at all. More on that below.

Put plainly, the green squares are a summary of public, default-branch activity, rendered by a service that has had an open incident since July. That's a weak basis for a hiring filter.

Why do green-square filters only fail in one direction?

Every known way the profile goes wrong hides real work, and none of them invents work that didn't happen. So a screen built on the profile produces false negatives, and you never see them. The rendering bug, the private-contribution toggle, unmerged branches and fork-only work all push the visible count down. None pushes it up.

That asymmetry is why the cost lands on the hiring side. A false positive shows up in the interview, where somebody notices the gap. A false negative is a candidate you dropped because their graph looked sparse, and you'll never learn you were wrong. The developer with 128 merged PRs would have failed any "active on GitHub" cutoff, while every API GitHub offers showed the opposite.

A green-squares cutoff never rejects a fake. It only rejects people whose work the page failed to draw.

This is the core of how to evaluate a GitHub profile for hiring. Treat the page as a lead, not a verdict. Then confirm against the API.

Why are badges a bad proxy for seniority?

Achievement badges are recalculated from the current public state of GitHub, so they can disappear for reasons that have nothing to do with the developer. Pull Shark is the badge for merged pull requests, and its tiers are 2, 16, 128 and 1,024 merged PRs (per discussion #208902).

128 is exactly the Pull Shark Silver threshold. The October bug didn't only hide a count. It hid a badge tier.

Badges also drop for legitimate reasons. When repos holding a developer's merged PRs are deleted or made private, GitHub recalculates the count, and it can fall below a tier. A badge measures what is public today, not lifetime output. Think about who that hurts most: a senior engineer whose employer takes a project private, or who moves into closed-source work, can lose a badge at the point in their career when they're most worth hiring.

GitHub doesn't hide this. Its own wording is "GitHub Achievements are in public preview and may change." Any screen that gives points for badges is scoring a preview feature.

How do you check a developer's real record through the API in five minutes?

Run three queries: merged PRs to repos the candidate doesn't own, PRs they reviewed for other people, and their restricted-contribution count. Together these cover the work the profile drops. You need the gh CLI and a logged-in GitHub account. Replace LOGIN with the candidate's username.

1. Merged PRs to repos they don't own

This is the most direct answer to "github api merged pull requests by user." Filtering out the user's own repos strips away self-merged work on personal projects.

gh search prs is:merged author:LOGIN -- -user:LOGIN

The -- stops the CLI from reading -user: as a flag. The minus operator is GitHub's documented exclusion rule. In the web search box, the same query is is:pr is:merged author:LOGIN -user:LOGIN. Look at which repos show up. A handful of merged PRs into a project with a real review process says more than a long streak on a personal repo.

2. Reviews on other people's work

gh search prs reviewed-by:LOGIN -- -author:LOGIN

reviewed-by: is a documented search qualifier. It lists pull requests where the candidate left a review, minus their own PRs. Weight this one highest. An approving review on someone else's pull request is a judgment call that only a trusted person gets to make, and it never appears as a green square. Commits show that someone can write code. Reviews show that a project lets them decide what ships. For staff or principal roles, where reviewing other people's work is the job, reviewed-by: deserves more weight than the commit count.

3. The contribution summary, including private work

gh api graphql -f query='
query {
  user(login: "LOGIN") {
    contributionsCollection {
      totalPullRequestReviewContributions
      restrictedContributionsCount
    }
  }
}'

totalPullRequestReviewContributions is the review count that the graph never draws. This follows a recent practitioner recipe: pull review contributions from contributionsCollection, then filter out authored PRs on repos the user owns. restrictedContributionsCount is, in GitHub's schema, "a count of contributions made by the user that the viewer cannot access," and it is only non-zero when the user has chosen to share private contribution counts.

4. Optional: a maintainer proxy

GitHub doesn't show who maintains what. Lorna Jane Mitchell's GraphQL approach checks authorCanPushToRepository on review contributions and treats it as a proxy for maintainer status: if the reviewer can push to the repo they're reviewing, they likely have a maintainer's standing there.

Five minutes is fine for one finalist. It doesn't scale to a long sourcing list, and those queries only work once you already have a username. That's the gap Refolk is built for: you describe the engineer in plain English (merged work in a given ecosystem, review activity, current employer) and get a ranked shortlist. You save the manual API pass for the people worth calling.

What does a restricted contribution count of zero mean?

It means "unknown," not "none." A restrictedContributionsCount of zero can mean the developer has no private work, or that they never turned on the setting that shares private contribution counts. You can't tell the two apart from the outside.

This is the heart of the "github private contributions recruiter" problem. A lot of professional engineering happens in private company repos. An engineer with years of closed-source work can have a nearly empty public graph and a substantial private record. Score their zero as a zero and you penalize them for working somewhere that keeps its code private.

What to do instead:

1. Treat a zero restricted count as missing data, not as a low score.
2. Ask the candidate to turn on private contribution sharing before a technical screen. It only shows anonymized counts, with no repo names.
3. Ask about private work directly in the first call: what they shipped, how big the team was, what they reviewed.
4. Weigh external merged PRs and reviews above volume. They're harder to fake and harder to hide.

Why can't you find maintainers by searching for "maintainer"?

Developers who maintain open source rarely label themselves that way, so keyword sourcing misses most of them. In Refolk's index, only 121 US profiles have "open source maintainer" in the headline. The same index holds 21,940 US professionals with Technical Recruiter or Technical Sourcer titles.

181 : 1

One caveat: these counts match headline keywords only, so they badly undercount real maintainers. That's the point. The 121 who do use the label include the lead maintainer of AboutCode's ScanCode, a CNCF staffer, and engineers at Docker, Okta/Auth0 and Union.ai. The German 46 include the YaCy maintainer and people at Datadog, NVIDIA and Dash0. The sample also includes Principal Engineers and a "VP OSS and Kubernetes." Maintainers are hiding under generic titles.

The recruiters in that index work at places like K2 Partnering Solutions, Experis, Snowflake, Google, Blue Origin and H2O.ai. With roughly 181 of them for every self-labeled maintainer, the label is the crowded channel. Activity data (reviewed-by:, merged PRs to repos the person doesn't own, push rights on what they review) finds the people who never wrote the word.

That search is hard to run by hand because it joins GitHub activity with employment history, two sources that don't talk to each other. In Refolk you write the sentence and get people matched on what they did, not what they called themselves.

FAQ

Is the GitHub profile rendering bug fixed?

Not as of the October 15, 2026 post in the thread. Discussion #203416 was opened as an incident on July 29, 2026, staff last updated it on September 23, and GitHub has said it doesn't have a timeline for a fix. Even after it's resolved, the profile will still leave out private work by default, along with fork-only work and review activity, so an API check is worth keeping.

How do I see all merged pull requests by a GitHub user?

Run gh search prs is:merged author:LOGIN with the GitHub CLI, or search is:pr is:merged author:LOGIN on github.com. Add -user:LOGIN to leave out the candidate's own repos, which gives you a cleaner view of work accepted by other maintainers.

Can recruiters see a developer's private contributions?

Only as anonymized counts, and only if the developer has turned on private contribution sharing. The API returns this as restrictedContributionsCount, which stays at zero when the setting is off. Treat a zero as unknown. Then ask the candidate to enable the setting or describe their private work in the screen.

Should I use GitHub achievement badges to rank candidates?

No. GitHub describes Achievements as a public preview that may change. Badges like Pull Shark (tiers at 2, 16, 128 and 1,024 merged PRs) are recalculated from currently public repos, so they can drop when a repo goes private, and the current incident has kept some from rendering at all. Use the API counts behind the badge instead.