Benchmark report
Is the GitHub API slow?
Response times from 5 cities
Slow from some locations
Singapore waited 469 ms, about 34× Tokyo. The gap suggests some test locations reach a distant server.
- Fastest
- 14 ms
- Tokyo
- Slowest
- 469 ms
- Singapore
- Successful requests
- 100%
- 5 of 6 locations
Response time around the world
Tokyo14 ms
Amsterdam30 ms
Montreal47 ms
San Francisco193 ms
Singapore469 ms
MumbaiCollecting since 7 Sept 2026
Why is Singapore slower?
In the controlled run of 7 September each city connected to a different address, and the connection time predicts the rest. Tokyo connected in 4 ms, finished TLS in 4 ms and waited 6 ms for the reply: 14 ms. Amsterdam connected in 9 ms and waited 9 ms, Montreal 15 and 15, San Francisco 63 and 62. Singapore connected in 154 ms, spent 156 ms on TLS and waited 178 ms: 489 ms in all. The wait for the first byte is about one round trip in every city, so GitHub answers this call almost as soon as it arrives; what differs is how far away the address each city was given turned out to be. The download was under 2 ms everywhere.
Click the location to see each stage.
Singapore489 ms
Singapore- Finding the server
- 2 ms
- Reaching the server
- 154 ms
- Setting up security
- 156 ms
- Waiting for the server: most of the time
- 178 ms
- Receiving the response
- 1 ms
- Total
- 489 ms
Finding the server is measured once per location, so it sits outside these bars. Open a city to see it.
Bars show the typical request, so the parts add up to its total. Why
Compare all locationsHide the comparison
Click a city to see its stage-by-stage breakdown.
Amsterdam29 ms
Amsterdam- Finding the server
- 1 ms
- Reaching the server
- 9 ms
- Setting up security: most of the time
- 11 ms
- Waiting for the server
- 9 ms
- Receiving the response
- 0 ms
- Total
- 29 ms
San Francisco190 ms
San Francisco- Finding the server
- 12 ms
- Reaching the server
- 63 ms
- Setting up security: most of the time
- 64 ms
- Waiting for the server
- 62 ms
- Receiving the response
- 1 ms
- Total
- 190 ms
Montreal46 ms
Montreal- Finding the server
- 1 ms
- Reaching the server
- 15 ms
- Setting up security: most of the time
- 16 ms
- Waiting for the server
- 15 ms
- Receiving the response
- 0 ms
- Total
- 46 ms
Singapore489 ms
Singapore- Finding the server
- 2 ms
- Reaching the server
- 154 ms
- Setting up security
- 156 ms
- Waiting for the server: most of the time
- 178 ms
- Receiving the response
- 1 ms
- Total
- 489 ms
Tokyo14 ms
Tokyo- Finding the server
- 1 ms
- Reaching the server
- 4 ms
- Setting up security
- 4 ms
- Waiting for the server: most of the time
- 6 ms
- Receiving the response
- 0 ms
- Total
- 14 ms
The phases come from the controlled run of 7 September 2026. Typical times pool daily requests; slower times use controlled full runs. 5 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo.
Finding the server is measured once per location, so it sits outside these bars. Open a city to see it.
Bars show the typical request, so the parts add up to its total. Why
GitHub still feels slow?
- Check GitHub’s status page
- API incidents are posted there and usually affect every city at once. A gap between cities is not an incident.
- This is not a git or authenticated API benchmark
- Authenticated calls, GraphQL, git clone and push, Actions, Packages and the signed-in site use other hosts and other paths.
- Five cities, five addresses
- Each city was given a different address for api.github.com in the controlled run, and how far away it was set the number. Singapore's 154 ms connection time says its address was far from Singapore. A slow result from Singapore or the US West Coast matches what we see; from Tokyo, Amsterdam or eastern North America it would be unusual.
Response time over the last 30 days
Show the numbers
| Day | Amsterdam | San Francisco | Montreal | Singapore | Tokyo | Mumbai |
|---|---|---|---|---|---|---|
| 27 August 2026 | 33 ms | 199 ms | 49 ms | 485 ms | 12 ms | — |
| 28 August 2026 | 30 ms | 201 ms | 47 ms | 463 ms | 15 ms | — |
| 29 August 2026 | 30 ms | 197 ms | 49 ms | 470 ms | 16 ms | — |
| 30 August 2026 | 29 ms | 194 ms | 47 ms | 465 ms | 14 ms | — |
| 31 August 2026 | 33 ms | 201 ms | 49 ms | 464 ms | 15 ms | — |
| 1 September 2026 | 31 ms | 194 ms | 47 ms | 462 ms | 14 ms | — |
| 2 September 2026 | 30 ms | 200 ms | 49 ms | 465 ms | 14 ms | — |
| 3 September 2026 | 30 ms | 191 ms | 47 ms | 461 ms | 14 ms | — |
| 4 September 2026 | 30 ms | 191 ms | 47 ms | 501 ms | 16 ms | — |
| 5 September 2026 | 29 ms | 191 ms | 50 ms | 501 ms | 15 ms | — |
| 6 September 2026 | 30 ms | 194 ms | 48 ms | 482 ms | 16 ms | — |
| 7 September 2026 | 28 ms | 192 ms | 47 ms | 477 ms | 14 ms | 23 ms |
| 8 September 2026 | 29 ms | 189 ms | 47 ms | 490 ms | 15 ms | 21 ms |
| 9 September 2026 | 29 ms | 194 ms | 46 ms | 460 ms | 14 ms | 25 ms |
| 10 September 2026 | 29 ms | 193 ms | 48 ms | 472 ms | 13 ms | 27 ms |
| 11 September 2026 | 29 ms | 192 ms | 49 ms | 477 ms | 14 ms | 23 ms |
| 12 September 2026 | 28 ms | 189 ms | 45 ms | 497 ms | 15 ms | 24 ms |
About this measurement
GET api.github.com/rate_limit · 70 requests per location over 14 daily runs · 30 August 2026 to 12 September 2026
What we tested · API response. GET api.github.com/rate_limit without a token: a 424-byte JSON reply from the API front end that does not count against the rate limit.
How LatencyRadar measures response time →Also measured: GitHub →
Technical details
Doesn’t measure: Authenticated calls, GraphQL, git over HTTPS, or the github.com site.
This report covers one GitHub surface: the REST API's rate-limit endpoint, called without a token. It returns 424 bytes of JSON from the API front end and does not count against the rate limit, which makes it the cheapest honest measure of reaching api.github.com. The github.com homepage has its own report. This call does not stand for authenticated API calls, GraphQL, or git over HTTPS, which use other hosts and other paths.
Not measured: authenticated REST calls, GraphQL, git clone and push, Actions, Packages, Codespaces or the signed-in site. From outside we see the address each city connected to and how long that took; we cannot see why GitHub's DNS or routing gave one city a nearby address and another a distant one.
Between 30 August and 12 September 2026 the typical time was 14 ms in Tokyo, 30 ms in Amsterdam and 47 ms in Montreal, against 193 ms in San Francisco and 469 ms in Singapore. Every city was steady. The daily medians moved by 3 to 5 ms in Tokyo, Amsterdam and Montreal, stayed between 189 and 201 ms in San Francisco and between 460 and 501 ms in Singapore, so the gap is steady rather than a bad week. Tokyo and Singapore connected to different addresses, and Singapore's 154 ms connection time says its address was far from Singapore; the two Asian cities are not served from one place. For a second unauthenticated developer API measured on the same days, see the GitLab API.
| Test location | Typical response time | Slower response time | Requests |
|---|---|---|---|
| Amsterdam | 30 ms | 32 ms | 20 |
| San Francisco | 193 ms | 195 ms | 20 |
| Montreal | 47 ms | 51 ms | 20 |
| Singapore | 469 ms | 549 ms | 20 |
| Tokyo | 14 ms | 20 ms | 20 |
| Mumbai | Collecting since 7 Sept 2026 | ||
Typical: half of the requests finished within this time (technical: p50). Slower: 95% of requests finished within this time (technical: p95). Statistics
- Request
- GET api.github.com/rate_limit
- Measured from
- Amsterdam · San Francisco · Montreal · Singapore · Tokyo
- Requests
- Daily measurements from 30 August 2026 to 12 September 2026. 5 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo. · 30 August 2026 to 12 September 2026
- Timings taken
- DNS, connect, TLS, waiting for the server, download
- Report coverage
- 5 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo.
- Daily requests in each location
- Amsterdam: 70 · San Francisco: 70 · Montreal: 70 · Singapore: 70 · Tokyo: 70
- Typical response time
- Median of the eligible daily requests in each included location.
- Slower response time
- Median of recent controlled full-run p95 values in each included location.
GitHub API
https://api.github.com/rate_limit
Independent measurement by LatencyRadar. Not affiliated with GitHub. · How we measure (v1.1)
How fast is your API around the world?
Run a free speed test from multiple cities and find out where your users are waiting. No setup, no account required.
No account required · Takes about 30 seconds.
