Benchmark report
Is the GitHub API slow?
Response times from 6 cities
Slow from some locations
Singapore waited 465 ms, about 36× Tokyo. The gap suggests some test locations reach a distant server.
- Fastest
- 13 ms
- Tokyo
- Slowest
- 465 ms
- Singapore
- Successful requests
- 100%
- 6 locations
Response time around the world
Tokyo13 ms
Mumbai26 ms
Amsterdam29 ms
Montreal47 ms
San Francisco194 ms
Singapore465 ms
Why is Singapore slower?
In the controlled run of 4 October each city connected to a different address, and the connection time predicts the rest. Tokyo connected in 3 ms, finished TLS in 4 ms and waited 6 ms for the reply: 13 ms. Mumbai connected in 6 ms and waited 7 ms, Amsterdam 8 and 9, Montreal 14 and 15, San Francisco 63 and 63. Singapore connected in 152 ms, spent 154 ms on TLS and waited 156 ms: 463 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.
Singapore463 ms
Singapore- Finding the server
- 4 ms
- Reaching the server
- 152 ms
- Setting up security
- 154 ms
- Waiting for the server: most of the time
- 156 ms
- Receiving the response
- 1 ms
- Total
- 463 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.
Amsterdam28 ms
Amsterdam- Finding the server
- 1 ms
- Reaching the server
- 8 ms
- Setting up security: most of the time
- 11 ms
- Waiting for the server
- 9 ms
- Receiving the response
- 0 ms
- Total
- 28 ms
San Francisco195 ms
San Francisco- Finding the server
- 21 ms
- Reaching the server
- 63 ms
- Setting up security: most of the time
- 69 ms
- Waiting for the server
- 63 ms
- Receiving the response
- 0 ms
- Total
- 195 ms
Montreal48 ms
Montreal- Finding the server
- 2 ms
- Reaching the server
- 14 ms
- Setting up security: most of the time
- 19 ms
- Waiting for the server
- 15 ms
- Receiving the response
- 0 ms
- Total
- 48 ms
Singapore463 ms
Singapore- Finding the server
- 4 ms
- Reaching the server
- 152 ms
- Setting up security
- 154 ms
- Waiting for the server: most of the time
- 156 ms
- Receiving the response
- 1 ms
- Total
- 463 ms
Tokyo13 ms
Tokyo- Finding the server
- 1 ms
- Reaching the server
- 3 ms
- Setting up security
- 4 ms
- Waiting for the server: most of the time
- 6 ms
- Receiving the response
- 0 ms
- Total
- 13 ms
Mumbai27 ms
Mumbai- Finding the server
- 3 ms
- Reaching the server
- 6 ms
- Setting up security: most of the time
- 14 ms
- Waiting for the server
- 7 ms
- Receiving the response
- 0 ms
- Total
- 27 ms
The phases come from the controlled run of 4 October 2026. Typical and slower times pool the daily requests. 6 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo, Mumbai.
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.
- Six cities, six 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 152 ms connection time says its address was far from Singapore; Mumbai's was 6 ms away. A slow result from Singapore or the US West Coast matches what we see; from Tokyo, Mumbai, Amsterdam or eastern North America it would be unusual.
Response time over the last 29 days
A dot marks a day well above that location’s usual level.
Show the numbers
| Day | Amsterdam | San Francisco | Montreal | Singapore | Tokyo | Mumbai |
|---|---|---|---|---|---|---|
| 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 |
| 13 September 2026 | 29 ms | 191 ms | 46 ms | 462 ms | 13 ms | 26 ms |
| 14 September 2026 | 31 ms | 191 ms | 47 ms | 463 ms | 13 ms | 24 ms |
| 15 September 2026 | 30 ms | 190 ms | 47 ms | 472 ms | 15 ms | 23 ms |
| 16 September 2026 | 31 ms | 194 ms | 46 ms | 493 ms | 14 ms | 24 ms |
| 17 September 2026 | 28 ms | 190 ms | 46 ms | 463 ms | 13 ms | 22 ms |
| 18 September 2026 | 29 ms | 198 ms | 45 ms | 486 ms | 14 ms | 23 ms |
| 19 September 2026 | 29 ms | 192 ms | 47 ms | 460 ms | 12 ms | 21 ms |
| 20 September 2026 | 29 ms | 193 ms | 46 ms | 461 ms | 14 ms | 25 ms |
| 21 September 2026 | 29 ms | 189 ms | 45 ms | 460 ms | 18 ms | 25 ms |
| 22 September 2026 | 32 ms | 200 ms | 46 ms | 466 ms | 12 ms | 25 ms |
| 23 September 2026 | 28 ms | 190 ms | 46 ms | 461 ms | 13 ms | 24 ms |
| 24 September 2026 | 52 ms | 190 ms | 46 ms | 463 ms | 13 ms | 23 ms |
| 25 September 2026 | 28 ms | 191 ms | 50 ms | 478 ms | 12 ms | 25 ms |
| 26 September 2026 | 29 ms | 190 ms | 46 ms | 465 ms | 12 ms | 27 ms |
| 27 September 2026 | 28 ms | 211 ms | 46 ms | 484 ms | 14 ms | 25 ms |
| 28 September 2026 | 28 ms | 191 ms | 53 ms | 485 ms | 13 ms | 24 ms |
| 29 September 2026 | 29 ms | 202 ms | 47 ms | 501 ms | 13 ms | 28 ms |
| 30 September 2026 | 29 ms | 200 ms | 47 ms | 462 ms | 13 ms | 26 ms |
| 1 October 2026 | 29 ms | 193 ms | 47 ms | 495 ms | 13 ms | 26 ms |
| 2 October 2026 | 28 ms | 194 ms | 95 ms ▲ | 463 ms | 13 ms | 25 ms |
| 3 October 2026 | 28 ms | 197 ms | 47 ms | 463 ms | 12 ms | 27 ms |
| 4 October 2026 | 29 ms | 194 ms | 56 ms | 461 ms | 13 ms | 26 ms |
| 5 October 2026 | 28 ms | 193 ms | 54 ms | 468 ms | 12 ms | 26 ms |
| 6 October 2026 | 29 ms | 193 ms | 48 ms | 459 ms | 12 ms | 26 ms |
| 7 October 2026 | 29 ms | 193 ms | 46 ms | 467 ms | 14 ms | 25 ms |
| 9 October 2026 | 30 ms | 194 ms | 46 ms | 462 ms | 13 ms | 25 ms |
| 10 October 2026 | 28 ms | 194 ms | 47 ms | 496 ms | 13 ms | 27 ms |
About this measurement
GET api.github.com/rate_limit · 65 requests per location over 13 daily runs · 27 September 2026 to 10 October 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.
Between 27 September and 10 October 2026 the typical time was 13 ms in Tokyo, 26 ms in Mumbai, 29 ms in Amsterdam and 47 ms in Montreal, against 194 ms in San Francisco and 465 ms in Singapore. Almost every day looked the same. The daily medians moved by 2 to 4 ms in Tokyo, Mumbai and Amsterdam, stayed between 191 and 211 ms in San Francisco and between 459 and 501 ms in Singapore, so the gap is steady rather than a bad week. The one outlier was Montreal at 95 ms on 2 October; on every other day it stayed between 46 and 56 ms. Mumbai was given an address 6 ms away and Tokyo one 3 ms away, while Singapore's was 152 ms away; the three Asian cities are not served from one place. 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. 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 | 29 ms | 33 ms | 65 |
| San Francisco | 194 ms | 205 ms | 65 |
| Montreal | 47 ms | 62 ms | 65 |
| Singapore | 465 ms | 508 ms | 65 |
| Tokyo | 13 ms | 19 ms | 65 |
| Mumbai | 26 ms | 29 ms | 65 |
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 · Mumbai
- Requests
- Daily measurements from 27 September 2026 to 10 October 2026. 6 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo, Mumbai. · 27 September 2026 to 10 October 2026
- Timings taken
- DNS, connect, TLS, waiting for the server, download
- Report coverage
- 6 of 6 test locations included: Amsterdam, San Francisco, Montreal, Singapore, Tokyo, Mumbai.
- Coverage changes
- Mumbai (measured since 7 September 2026) joined this report on 21 September 2026. Earlier daily bands keep their previous location set.
- Daily requests in each location
- Amsterdam: 65 · San Francisco: 65 · Montreal: 65 · Singapore: 65 · Tokyo: 65 · Mumbai: 65
- Typical response time
- Median of the eligible daily requests in each included location.
- Slower response time
- The 95th percentile of the same eligible daily requests in each included location.
GitHub API
https://api.github.com/rate_limit
Independent measurement by LatencyRadar. Not affiliated with GitHub. · How we measure (v1.3)
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.
