GitHub Rate Limited Me With a Token Set

I wired the GitHub API into a site of mine, with a personal access token set, and GitHub still rate limited me. That surprised me, because the token is meant to be the answer. Waiting it out took 15 to 30 minutes each time, which is long enough to stop work. What fixed it was moving the call out of runtime and fetching the data at build time instead, so the site stopped asking GitHub anything while people were using it.

If you are picking a free API to build on, this is the thing I would check before anything else: whether you can still be stopped after you have done the paperwork.

Two sets of limits, and the token only helps with one

I had assumed the rate limit was one number and the token raised it. There are two sets of numbers, and the token raises the first set only.

Limit	What GitHub documents
Primary, no token	60 requests an hour
Primary, personal access token	5,000 requests an hour
Secondary, concurrency	No more than 100 concurrent requests
Secondary, throughput	No more than 900 points a minute on REST, 2,000 on GraphQL
Secondary, CPU	No more than 90 seconds of CPU time per 60 seconds of real time
Secondary, writes	No more than 80 content-generating requests a minute, 500 an hour

All from GitHub's REST rate limit documentation, read on 2 October 2026.

I cannot tell you which of those secondary limits I hit. I did not instrument it, and I am not going to pretend otherwise. What I can tell you is that I was nowhere near 5,000 requests an hour when it happened, which is enough to know the primary number was never the one that mattered.

The wait is the part that hurt

GitHub's guidance for a secondary limit is to wait at least one minute before retrying. Mine took 15 to 30 minutes.

"At least one minute" is accurate and also not very useful, because the floor tells you nothing about the ceiling. A one minute block is something you retry through; a 20 minute block is an outage, and I had built as though the first was what I had.

And this is a limit you discover in production, not in development. On my own machine I reload a page a few times and nothing complains. The limit arrives when a real number of requests land in a real window, which is after the thing is live and in front of people.

Moving it to build time

The fix was to stop asking GitHub anything while the site was serving.

The data I wanted does not change between one visitor and the next, which means fetching it per request was work I was choosing to do. Pulling it once at build time means GitHub sees a handful of requests per deploy rather than one per page view, and no visitor is ever waiting on an API that might be refusing me. If GitHub blocks a build, I find out in the build log, which is a far better place to learn it than a page that half renders.

This is the same trade I ran into with caching in Next.js 16: something has to pay for the data, and paying at build time is usually cheaper than making the request path cleverer.

The cost is freshness. Build-time data is as old as your last deploy. For what I was showing, a deploy old is fine. If your data has to be current to the minute, you are back to runtime calls and you need to handle the block properly, which means reading the retry headers and having something sensible to render when the answer is no.

What to check before you build on a free API

Find the secondary limits, not just the headline number. If the docs only advertise requests per hour, look for a concurrency or throughput limit underneath. Then find out what a block looks like: the status code, the headers, and how long it actually lasts rather than the minimum the docs promise. And decide early whether the data can be fetched once per deploy, because if it can, most of this stops being your problem.