/stats/contributors never returns a response, only HTTP status code 202 forever

[jstrieb]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

The /repos/{owner}/{repo}/stats/contributors API endpoint is broken.

This endpoint is supposed to return an empty response with an HTTP 202 status code until a background job has computed aggregate statistics, at which point the endpoint returns the data and an HTTP 200 status code on the subsequent request. Instead, as of a few days ago, it returns 202 forever, and never returns a 200 with the data. The endpoint currently misbehaves this way with every repository I have tested. This API failure started sometime between April 12 and April 13.

I maintain a modestly popular project to generate GitHub statistics images, which uses this API. One of the key statistics (lines of code changed) is broken for every user until this problem is fixed.

---

I noticed that the contributors page for each repo now requests a non-API endpoint to get the same data (https://github.com/jstrieb/github-stats/graphs/contributors-data). That new path has a similar pattern of returning 202, then eventually returning data, and the returned data has similar schema to the original stats endpoint. The new page doesn't seem to have reliability issues, but is also not a documented API for accessing this data. As an API consumer, it's frustrating that the data is still clearly available, just not to me.

There is nothing in the GitHub blog "changelog" mentioning adjustments to the behavior of this API, nor is there any information about a breaking change on the API documentation page for such changes. There is likewise no mention of this bug in the product roadmap. That leads me to believe that this is an unintended bug.

---

To replicate the failure: make a request to /repos/{owner}/{repo}/stats/contributors for any repo using a GitHub authentication token in a loop. Doing so with no timeout, a fixed timeout, or with exponential backoff makes no difference. The API will return 202 forever.

Without exponential backoff:

while true; do
  curl \
    --location \
    --silent \
    --write-out "%{http_code}\n" \
    --output /dev/null \
    -H "Accept: application/vnd.github+json" \
    -H "Authorization: Bearer [...]" \
    -H "X-GitHub-Api-Version: 2026-03-10" \
    'https://api.github.com/repos/jstrieb/github-stats/stats/contributors'
  sleep 2
done

With exponential backoff:

SLEEP=2
while true; do
  curl \
    --location \
    --silent \
    --write-out "%{http_code}\n" \
    --output /dev/null \
    -H "Accept: application/vnd.github+json" \
    -H "Authorization: Bearer [...]" \
    -H "X-GitHub-Api-Version: 2026-03-10" \
    'https://api.github.com/repos/jstrieb/github-stats/stats/contributors'
  sleep "${SLEEP}"
  SLEEP=$(( SLEEP * 2 ))
done

I've let the scripts above run for many hours and they never terminate.

---

Possible duplicate of #192571.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[R055A]

There is an alternative solution for scraping contribution stats in README repo pins.

Aside for this, I learned much from your repository back in early 2021.

[jstrieb]

This looks very similar to what I added to github-stats a few days ago! Great minds think alike, I guess 😄

Unfortunately, I can't get it to exactly match GitHub's returned version due to inconsistencies in how I count contributions versus how they do it. I'd rather the API work, but calculating from local clones is an acceptable fallback for now.

Hopefully you only picked up the few good nuggets from that repo and left the bad bits behind! I've very recently rewritten it, but the old code was not my best work.

[R055A]

This looks very similar to what I added to github-stats a few days ago! Great minds think alike, I guess 😄

Looks very good.

Unfortunately, I can't get it to exactly match GitHub's returned version due to inconsistencies in how I count contributions versus how they do it. I'd rather the API work, but calculating from local clones is an acceptable fallback for now.

I find the alternative solution is more computationally efficient in a time-resource trade-off, even if the API is returning desired results. However, when I first experimented with this the commit history scraped per repo was limited to no more than a few hours, while there was no limitation to the number of repositories. This was not for readme-repo-pins-src where all commit history per repo is scraped.

Regarding commits with multiple authors, without reviewing what I did last year, I vaguely recollect the count being evenly split between the number of co-authors. This is an assumed fairness, but based on knowing I am never below a fair split.

Hopefully you only picked up the few good nuggets from that repo and left the bad bits behind! I've very recently rewritten it, but the old code was not my best work.

If you like, you can view for yourself here: profile-icons/git-stats. It is not the original template-generated repo from early 2021 - I deleted this because of plagiarism issues (not by myself or relevant to your repo).

Your original repo is very good. I learned a lot from it.

Regarding the language scraping stats issue, scraping from the commit history may provide a solution to this, if not already.

[Phosphorus-M]

Yeah same problem

[zak7din]

https://github.com/orgs/community/discussions/192970

[bizbazboz]

Yeah same issue

[Leocm123]

This is a known regression in the /stats/contributors endpoint that started around April 12-13, 2026. The endpoint is indefinitely returning 202 without ever computing the stats.

Workaround: As the OP discovered, GitHub's own contributors page now uses an undocumented endpoint that still works:

GET https://github.com/{owner}/{repo}/graphs/contributors-data

This endpoint follows the same 202 → 200 polling pattern as the original API. Example with curl:

# Poll until you get a 200
while true; do
  response=$(curl -s -o /tmp/stats.json -w "%{http_code}" \
    -H "Accept: application/json" \
    https://github.com/{owner}/{repo}/graphs/contributors-data)
  if [ "$response" = "200" ]; then
    cat /tmp/stats.json
    break
  fi
  sleep 3
done

The response schema is very similar to the original /stats/contributors endpoint. It's not officially documented, so use with caution — but it's the best available workaround until GitHub fixes the regression.

I'd also recommend opening a support ticket at https://support.github.com/contact to help escalate the fix.

[jstrieb]

Where do you see acknowledgement that this is a "known regression"? I couldn't find anything from GitHub saying that.

Also, as far as I can tell, using that endpoint is not a viable alternative. My use case involves hitting the original endpoint for tens to hundreds of repositories, so I need to be able to use my authentication token to ensure I don't hit API rate limits. This page seems to be authenticated using a client session cookie, and doesn't support a bearer token for authentication. I tested before posting this discussion, and it will not work for my needs.

[Leocm123]

Thanks for the corrections — you’re right on both points. I should not have called it a “known regression” without an official GitHub acknowledgment; that was based on user reports, not confirmed by GitHub. And regarding the alternative endpoint: if your use case requires authenticated requests with a bearer token across many repositories, graphs/contributors-data won’t work since it relies on session cookies only. The honest answer here is to open a support ticket and wait for GitHub to fix the original endpoint. Sorry for the misleading suggestions.

[jstrieb]

Also this is a better support URL: https://support.github.com/contact/bug-report

They don't seem to list the bug report URL on their support page (see screenshot below). But the URL I include will actually allow filing a bug report.

[Leocm123]

Good point on both — thanks for the corrections.
For anyone hitting this issue, the most direct way to report it to GitHub is via their (unlisted) bug report form:
https://support.github.com/contact/bug-report
This doesn’t appear on the main support page, but it’s the right channel for filing API regressions like this one.

[Leocm123]

[jstrieb]

This is a duplicate of the reply above and should maybe be deleted?

[dparker1005]

I just migrated my app GitPacks (generates collectable "trading cards" for contributors to GitHub repos) to pull the commit history via GraphQL and calculate the stats with that data. Seems to be working well as a workaround for now:
dparker1005/GitPacks@c4f473d

[jstrieb]

How does the time required to compute the metrics compare with the working version of this contributor stats API endpoint? How does the time compare to cloning and computing locally? What's the API token usage (as a fraction of hourly rate limit)?

I considered this strategy, but didn't end up testing it out, so I'm curious to hear more about how it's working for you.

[dparker1005]

Honestly, I pretty much monitored Claude as he one-shot this migration, but everything seems to have gone smoothly. Granted, there's not a lot of traffic at all so I am able to vibe code freely and rate limiting isn't much of an issue for us, but is definitely something that was considered.

Claude's answers to your questions while he still has the context of this work:

• Time vs working /stats/contributors: Can't say — no side-by-side measurements since the old endpoint is broken on every repo I tested. Subjectively no regression for users.
• Time vs cloning locally: Didn't try. We deploy on Vercel Hobby (no git binary in the runtime, 500MB /tmp, 60s function cap), so cloning wasn't a realistic option. If your runtime supports it, clone is presumably faster.
• API usage: Per https://docs.github.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api, history(first: 100) works out to 1 point per page. We cap at 50K commits (anything larger gets rejected up front), so a max-size repo is ~500 points = 10% of the 5,000/hr budget. Each logged-in user uses their own OAuth token, so per-user pressure is negligible.

Two design choices that we made worth flagging:

• Probe with repository.history(first: 0).totalCount first — 1 point, lets you reject oversized repos (50K+ commits) before committing to the fanout.
• 8-way time-bucket fanout (split [createdAt, now] into N date ranges, paginate each in parallel) to sidestep the fact that GraphQL cursors don't parallelize within a single connection.

Code is at https://github.com/dparker1005/GitPacks/blob/main/app/lib/github-stats.ts if anyone wants to lift the bucketing.

[michaelmworthington]

It looks like this is working on one of my repositories again. Has anyone else observed the same?

[jstrieb]

I reached out to GitHub support in May, and about a month ago, they replied that it had been fixed.

Hi Jacob,

Our engineering team have reached out to let me know that, after some improvements made to our backend caching system, these endpoints should now behave as expected!

Thank you for your patience as we addressed this problem, if you are still experiencing the same issue, please don't hesitate to reach out!

Roy
GitHub Support

Details