Benchmark report
Is the GitLab API slow?
Response times from 5 cities
Slow from some locations
No city came in under 200 ms: Montreal was quickest at 211 ms and Singapore slowest at 395 ms. Most of that wait is present everywhere, so distance explains only part of it.
- Fastest
- 211 ms
- Montreal
- Slowest
- 395 ms
- Singapore
- Successful requests
- 100%
- 5 of 6 locations
Response time around the world
Montreal211 ms
San Francisco234 ms
Amsterdam265 ms
Tokyo379 ms
Singapore395 ms
MumbaiCollecting since 7 Sept 2026
Why is no city under 200 ms?
In the controlled run of 7 September connecting and the TLS handshake took 12 to 26 ms in every city and the download 0 to 3 ms. The rest was waiting for the first byte: 203 ms in San Francisco, 206 ms in Montreal, 255 ms in Amsterdam, 364 ms in Tokyo and 367 ms in Singapore. All five 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 200 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.
Singapore391 ms
Singapore- Finding the server
- 2 ms
- Reaching the server
- 4 ms
- Setting up security
- 17 ms
- Waiting for the server: most of the time
- 367 ms
- Receiving the response
- 3 ms
- Total
- 391 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.
Amsterdam281 ms
Amsterdam- Finding the server
- 1 ms
- Reaching the server
- 11 ms
- Setting up security
- 15 ms
- Waiting for the server: most of the time
- 255 ms
- Receiving the response
- 0 ms
- Total
- 281 ms
San Francisco217 ms
San Francisco- Finding the server
- 11 ms
- Reaching the server
- 4 ms
- Setting up security
- 10 ms
- Waiting for the server: most of the time
- 203 ms
- Receiving the response
- 0 ms
- Total
- 217 ms
Montreal221 ms
Montreal- Finding the server
- 1 ms
- Reaching the server
- 3 ms
- Setting up security
- 12 ms
- Waiting for the server: most of the time
- 206 ms
- Receiving the response
- 0 ms
- Total
- 221 ms
Singapore391 ms
Singapore- Finding the server
- 2 ms
- Reaching the server
- 4 ms
- Setting up security
- 17 ms
- Waiting for the server: most of the time
- 367 ms
- Receiving the response
- 3 ms
- Total
- 391 ms
Tokyo377 ms
Tokyo- Finding the server
- 1 ms
- Reaching the server
- 2 ms
- Setting up security
- 10 ms
- Waiting for the server: most of the time
- 364 ms
- Receiving the response
- 1 ms
- Total
- 377 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
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 five 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 30 days
Show the numbers
| Day | Amsterdam | San Francisco | Montreal | Singapore | Tokyo | Mumbai |
|---|---|---|---|---|---|---|
| 28 August 2026 | 237 ms | 194 ms | 176 ms | 357 ms | 275 ms | — |
| 29 August 2026 | 231 ms | 195 ms | 142 ms | 339 ms | 285 ms | — |
| 30 August 2026 | 224 ms | 320 ms | 187 ms | 334 ms | 312 ms | — |
| 31 August 2026 | 265 ms | 201 ms | 193 ms | 378 ms | 263 ms | — |
| 1 September 2026 | 211 ms | 195 ms | 235 ms | 341 ms | 291 ms | — |
| 2 September 2026 | 259 ms | 226 ms | 203 ms | 379 ms | 491 ms | — |
| 3 September 2026 | 271 ms | 274 ms | 204 ms | 394 ms | 450 ms | — |
| 4 September 2026 | 260 ms | 238 ms | 188 ms | 449 ms | 399 ms | — |
| 5 September 2026 | 257 ms | 245 ms | 313 ms | 403 ms | 373 ms | — |
| 6 September 2026 | 276 ms | 218 ms | 286 ms | 403 ms | 371 ms | — |
| 7 September 2026 | 309 ms | 233 ms | 317 ms | 450 ms | 437 ms | 482 ms |
| 8 September 2026 | 272 ms | 226 ms | 218 ms | 388 ms | 393 ms | 472 ms |
| 9 September 2026 | 256 ms | 418 ms | 248 ms | 390 ms | 381 ms | 477 ms |
| 10 September 2026 | 262 ms | 238 ms | 197 ms | 421 ms | 385 ms | 479 ms |
| 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 |
About this measurement
GET gitlab.com/api/v4/projects/278964 · 70 requests per location over 14 daily runs · 30 August 2026 to 12 September 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.
Not measured: git clone, fetch and push, CI runners and job queues, the container and package registries, GraphQL, or the signed-in application. 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 30 August and 12 September 2026 the typical time ranged from 211 ms in Montreal to 395 ms in Singapore, with San Francisco at 234 ms, Amsterdam at 265 ms and Tokyo at 379 ms. The daily medians drifted upward during the window. Amsterdam ran at 211 to 265 ms until 1 September and at 256 to 309 ms from 2 September; Singapore moved from 334 to 378 ms up to 379 to 450 ms, and Tokyo from 263 to 312 ms up to 367 to 491 ms, on the same dates. We cannot see from outside what changed on 2 September. 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 | 265 ms | 304 ms | 20 |
| San Francisco | 234 ms | 286 ms | 20 |
| Montreal | 211 ms | 263 ms | 20 |
| Singapore | 395 ms | 415 ms | 20 |
| Tokyo | 379 ms | 400 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 gitlab.com/api/v4/projects/278964
- 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.
GitLab REST API
https://gitlab.com/api/v4/projects/278964
Independent measurement by LatencyRadar. Not affiliated with GitLab. · 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.
