Benchmark report
Is the GitLab API slow?
Response times from 6 cities
Slow from some locations
No city came in under 200 ms: Montreal was quickest at 205 ms and Mumbai slowest at 484 ms. Most of that wait is present everywhere, so distance explains only part of it.
- Fastest
- 205 ms
- Montreal
- Slowest
- 484 ms
- Mumbai
- Successful requests
- 100%
- 6 locations
Response time around the world
Montreal205 ms
San Francisco242 ms
Amsterdam266 ms
Tokyo387 ms
Singapore407 ms
Mumbai484 ms
Why is no city under 200 ms?
In the controlled run of 4 October connecting and the TLS handshake took 9 to 23 ms in every city and the download 0 to 1 ms. The rest was waiting for the first byte: 184 ms in Montreal, 211 ms in San Francisco, 250 ms in Amsterdam, 368 ms in Tokyo, 382 ms in Singapore and 444 ms in Mumbai. All six cities connected to the same Cloudflare address and the cache header named a nearby point of presence, so the wait is the trip from that edge to GitLab plus the time GitLab spends on the request. With no city below 180 ms even from the nearest edge, a good part of that wait appears to be the request itself rather than distance.
Click the location to see each stage.
Mumbai454 ms
Mumbai- Finding the server
- 4 ms
- Reaching the server
- 2 ms
- Setting up security
- 8 ms
- Waiting for the server: most of the time
- 444 ms
- Receiving the response
- 0 ms
- Total
- 454 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.
Amsterdam273 ms
Amsterdam- Finding the server
- 1 ms
- Reaching the server
- 9 ms
- Setting up security
- 14 ms
- Waiting for the server: most of the time
- 250 ms
- Receiving the response
- 0 ms
- Total
- 273 ms
San Francisco222 ms
San Francisco- Finding the server
- 13 ms
- Reaching the server
- 3 ms
- Setting up security
- 8 ms
- Waiting for the server: most of the time
- 211 ms
- Receiving the response
- 0 ms
- Total
- 222 ms
Montreal195 ms
Montreal- Finding the server
- 1 ms
- Reaching the server
- 2 ms
- Setting up security
- 8 ms
- Waiting for the server: most of the time
- 184 ms
- Receiving the response
- 1 ms
- Total
- 195 ms
Singapore395 ms
Singapore- Finding the server
- 7 ms
- Reaching the server
- 3 ms
- Setting up security
- 10 ms
- Waiting for the server: most of the time
- 382 ms
- Receiving the response
- 0 ms
- Total
- 395 ms
Tokyo377 ms
Tokyo- Finding the server
- 1 ms
- Reaching the server
- 3 ms
- Setting up security
- 6 ms
- Waiting for the server: most of the time
- 368 ms
- Receiving the response
- 0 ms
- Total
- 377 ms
Mumbai454 ms
Mumbai- Finding the server
- 4 ms
- Reaching the server
- 2 ms
- Setting up security
- 8 ms
- Waiting for the server: most of the time
- 444 ms
- Receiving the response
- 0 ms
- Total
- 454 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
GitLab still feels slow?
- Check GitLab’s status page
- API and platform incidents are posted there before they show up in a benchmark.
- This is not a git or CI benchmark
- git over HTTPS, CI runners, the container and package registries, GraphQL and the signed-in application are not measured here.
- Nothing is cached
- One Cloudflare address for all six cities, each answered from a nearby point of presence (London for Amsterdam). The response is private, so every call waits for GitLab. Montreal and San Francisco had the shortest waits, which suggests GitLab's origin is in North America.
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 | 278 ms | 234 ms | 198 ms | 413 ms | 367 ms | 446 ms |
| 12 September 2026 | 287 ms | 227 ms | 185 ms | 420 ms | 374 ms | 498 ms |
| 13 September 2026 | 287 ms | 231 ms | 275 ms | 444 ms | 414 ms | 493 ms |
| 14 September 2026 | 258 ms | 278 ms | 215 ms | 421 ms | 377 ms | 520 ms |
| 15 September 2026 | 265 ms | 226 ms | 253 ms | 417 ms | 375 ms | 466 ms |
| 16 September 2026 | 269 ms | 222 ms | 212 ms | 450 ms | 407 ms | 495 ms |
| 17 September 2026 | 241 ms | 296 ms | 189 ms | 393 ms | 376 ms | 511 ms |
| 18 September 2026 | 284 ms | 248 ms | 192 ms | 428 ms | 379 ms | 526 ms |
| 19 September 2026 | 278 ms | 214 ms | 220 ms | 440 ms | 371 ms | 471 ms |
| 20 September 2026 | 241 ms | 238 ms | 202 ms | 401 ms | 393 ms | 494 ms |
| 21 September 2026 | 268 ms | 291 ms | 240 ms | 1023 ms ▲ | 395 ms | 486 ms |
| 22 September 2026 | 264 ms | 235 ms | 216 ms | 387 ms | 402 ms | 494 ms |
| 23 September 2026 | 283 ms | 270 ms | 196 ms | 688 ms | 383 ms | 495 ms |
| 24 September 2026 | 265 ms | 247 ms | 181 ms | 440 ms | 380 ms | 502 ms |
| 25 September 2026 | 268 ms | 484 ms ▲ | 195 ms | 656 ms | 395 ms | 817 ms |
| 26 September 2026 | 281 ms | 454 ms | 197 ms | 414 ms | 419 ms | 591 ms |
| 27 September 2026 | 283 ms | 221 ms | 206 ms | 405 ms | 380 ms | 636 ms |
| 28 September 2026 | 259 ms | 254 ms | 194 ms | 847 ms ▲ | 399 ms | 484 ms |
| 29 September 2026 | 276 ms | 255 ms | 193 ms | 411 ms | 427 ms | 504 ms |
| 30 September 2026 | 277 ms | 231 ms | 192 ms | 455 ms | 401 ms | 466 ms |
| 1 October 2026 | 269 ms | 273 ms | 205 ms | 465 ms | 415 ms | 474 ms |
| 2 October 2026 | 260 ms | 287 ms | 216 ms | 762 ms | 393 ms | 461 ms |
| 3 October 2026 | 253 ms | 229 ms | 210 ms | 388 ms | 389 ms | 461 ms |
| 4 October 2026 | 257 ms | 262 ms | 203 ms | 399 ms | 373 ms | 458 ms |
| 5 October 2026 | 277 ms | 242 ms | 214 ms | 385 ms | 381 ms | 485 ms |
| 6 October 2026 | 261 ms | 228 ms | 206 ms | 395 ms | 383 ms | 473 ms |
| 7 October 2026 | 296 ms | 251 ms | 204 ms | 395 ms | 374 ms | 502 ms |
| 9 October 2026 | 259 ms | 237 ms | 202 ms | 441 ms | 424 ms | 498 ms |
| 10 October 2026 | 232 ms | 190 ms | 143 ms | 376 ms | 325 ms | 357 ms |
About this measurement
GET gitlab.com/api/v4/projects/278964 · 65 requests per location over 13 daily runs · 27 September 2026 to 10 October 2026
What we tested · API response. GET /api/v4/projects/278964 (gitlab-org/gitlab): 1.2 KB of JSON, no token, behind Cloudflare but marked private so every request reaches GitLab.
How LatencyRadar measures response time →
Technical details
Doesn’t measure: Authenticated calls, git over HTTPS, CI runners, or the gitlab.com site.
One GitLab surface: the REST API's project record for gitlab-org/gitlab, 1.2 KB of JSON fetched without a token. The response is marked private, so Cloudflare passes every request through to GitLab, and the number is the cost of an unauthenticated API call as a CI script or integration would make it. It does not stand for git over HTTPS, for authenticated calls, which have their own rate limits, or for the gitlab.com website. From outside we cannot separate the round trip from Cloudflare's edge to GitLab's origin from the time GitLab spends assembling the record; the wait we report contains both.
Between 27 September and 10 October 2026 the typical time ranged from 205 ms in Montreal to 484 ms in Mumbai, with San Francisco at 242 ms, Amsterdam at 266 ms, Tokyo at 387 ms and Singapore at 407 ms. The daily medians were mostly steady: Amsterdam stayed between 232 and 296 ms and Tokyo between 325 and 427 ms on every run. Three days stand out: Mumbai at 636 ms on 27 September, and Singapore at 847 ms on 28 September and 762 ms on 2 October. The pooled typical absorbs them. The last run, on 10 October, was the quickest of the two weeks in every city, with Montreal at 143 ms. The gap between Montreal and Mumbai, about 280 ms, is consistent with the extra round trip from Cloudflare's Mumbai edge to an origin in North America; the 200 ms or so that every city pays is the request itself. For the same kind of unauthenticated call to another code host, see the GitHub API page, measured on the same days; its numbers are set by distance to the address each city was given, while these carry a wait that is present in every city.
| Test location | Typical response time | Slower response time | Requests |
|---|---|---|---|
| Amsterdam | 266 ms | 347 ms | 65 |
| San Francisco | 242 ms | 304 ms | 65 |
| Montreal | 205 ms | 260 ms | 65 |
| Singapore | 407 ms | 833 ms | 65 |
| Tokyo | 387 ms | 476 ms | 65 |
| Mumbai | 484 ms | 636 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 gitlab.com/api/v4/projects/278964
- 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.
GitLab REST API
https://gitlab.com/api/v4/projects/278964
Independent measurement by LatencyRadar. Not affiliated with GitLab. · 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.
