Rate-Limit Threshold Interaction With Pipeline Concurrency

Investigate how GitLab's configured API rate‑limit ceiling influences overall CI/CD pipeline throughput when max concurrent pipelines is adjusted. The default user‑level limit of 1000 requests per minute, configurable per instance via the rate_limit setting, interacts with pipeline concurrency controls under admin settings. When pipeline execution generates API calls that exceed this threshold, HTTP 429 responses with Retry‑After headers may stall job startups, and the extent to which pipeline concurrency settings amplify or mitigate this effect remains undocumented for mixed‑user runner environments.

Key uncertainties include whether the rate‑limit applies per‑user, per‑project, or per‑instance during concurrent pipeline runs, and how Retry‑After timing impacts queuing behavior when multiple pipelines compete for API slots. Differences between GitLab.com and self‑hosted instances further complicate threshold predictions, as do variations in runner registration scope and token scope.

What measurable threshold exists where increasing max concurrent pipelines ceases to improve throughput under the default 1000 requests per minute user limit? Does the Retry‑After header behavior differ when the limit is exceeded during pipeline startup versus mid‑execution job steps? How do per-instance rate‑limit overrides alter pipeline queuing when multiple projects share a single runner under a common user context?