Rate limit hitting soon after the cool time

[aupadhyay-comm]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

curl-err:[No error] http-resp:[403] url:[https://api.github.com/repos/clumio/cdf/issues/45012/comments?sort=updated&per_page=100] server-resp:[{
"message": "API rate limit exceeded for user ID . If you reach out to GitHub Support for help, please include the request ID 5E01:5A84C:B72AAF5:30247802:69DBE20B and timestamp 2026-04-12 18:18:51 UTC. For more on scraping GitHub and how it may affect your rights, please review our Terms of Service (https://docs.github.com/en/site-policy/github-terms/github-terms-of-service)",
"documentation_url": "https://docs.github.com/en/rest/using-the-rest-api/getting-started-with-the-rest-api#rate-limiting",
"status": "403"
}
] resp-size:[538]
3633311 377133 04/12 13:18:51 42327768 CGitHubConnection::ExecuteRequestWithRetry(70) - The GitHub API Interface has reached the rate limit
3633311 377133 04/12 13:18:51 42327768 CGitConnection::SleepBeforeRetry(229) - API rate limit reset header:[X-RateLimit-Reset: 1776020462]
3633311 377133 04/12 13:18:51 42327768 CGitConnection::SleepBeforeRetry(238) - API rate limit reset time:[1776020462]
3633311 377133 04/12 13:18:51 42327768 CGitConnection::SleepBeforeRetry(249) - Will retry after 2531 seconds

We are hitting this rate limit every one hour . Could someone please help here ? We are using single pat for this and soon after the wait time overs for the rate limit we are getting another rate limit. How this can possible. According to documentation , its 5000 API per hour atleast right?

[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. ⭐

[Gecko51]

If you're burning through 5000 requests/hr with a single PAT, a few things to check:

First, look at the X-RateLimit-Remaining and X-RateLimit-Used headers in your API responses. That'll tell you exactly how many calls you're making per window. If the count is way higher than you expected, something in your tooling might be polling in a tight loop or retrying failed requests without backing off properly.

From your logs it looks like you're hitting /repos/{owner}/{repo}/issues/{id}/comments?sort=updated&per_page=100. If you're iterating over a large number of issues and fetching comments for each one, that adds up fast. Say you have 500 issues and each needs at least one call for comments, you're already at 500+ requests just for that.

A couple things that help:

1. Use conditional requests. Send an If-None-Match header with the ETag from your previous response. If nothing changed, the API returns a 304 and it doesn't count against your rate limit. Huge savings if you're polling the same endpoints repeatedly.
2. Switch to a GitHub App instead of a PAT. App installation tokens get their own 5000 req/hr limit, and if you install the app on multiple orgs, each installation gets a separate pool. With a single PAT, everything shares one bucket.
3. Check if other tools or CI pipelines are using that same PAT. The limit is per token, so if your PAT is also used in Actions workflows or other integrations, they're all eating from the same pool.
4. Use the REST API's since parameter on the issues/comments endpoints to only fetch stuff that changed since your last sync, instead of pulling everything every time.
   The 2531 second sleep in your logs (about 42 minutes) also looks odd, that should be closer to 3600 seconds if you're waiting for a full hour reset. Double check the X-RateLimit-Reset timestamp math in your retry logic.

What tool are you using on top of the API? That might help narrow it down.

[lokeshwardewangan]

It looks like this is not the normal 5000/hr rate limit issue, but more likely GitHub’s secondary rate limiting kicking in.

This usually happens when there are too many requests in a short burst (parallel calls, frequent polling, or retries happening together), even if you are technically under 5000 requests/hour.

Since you are using a single PAT, all requests are counted together — so if multiple processes/threads are hitting the API or retrying at the same time after reset, it can immediately trigger the limit again.

You can try a few things:

• Add some delay/throttling instead of sending requests in bursts
• Avoid multiple parallel requests if possible
• Make sure retries are not happening all at once after reset
• Reduce polling frequency (or use caching with ETag)
• If possible, avoid sharing a single PAT across everything

Overall, this behavior is expected when request patterns are too aggressive, even if the hourly limit hasn’t been fully consumed.