Last update: 10 October 2026. We haven't refreshed this page since, so today's response times may be different.
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?
Our Singapore server takes the long way to GitHub. GitHub's DNS sends Singapore to a GitHub server in Singapore, but our hosting provider routes traffic for Microsoft's network, where that server runs, through Marseille and Paris and back. Each round trip takes about 150 ms, and a new connection needs three: 152 ms to connect, 154 ms to set up the secure connection and 156 ms waiting for the reply, 463 ms in all in the controlled run of 4 October. In Tokyo the same three steps took 3, 4 and 6 ms. A Singapore network that reaches Microsoft directly should get much closer to Tokyo's time; we haven't measured one yet.
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.
- Singapore and San Francisco measure our network
- Singapore's route to GitHub detours through France. San Francisco's DNS server is registered in Virginia, so GitHub sends that test to Virginia. Looked up for the San Francisco server's own network, GitHub returns a western US server instead, and the same call took about 90 ms in a quick check.
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. Both slow cities say more about our test network than about GitHub: Singapore's route detours through France, and San Francisco goes to Virginia because that's where our DNS server is registered. Tokyo, Mumbai, Amsterdam and Montreal each reached a GitHub server 3 to 14 ms away. 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.
