GitLab.com переводит лимиты API на тарифы: неавторизованным — 60 запросов в час вместо 500 в минуту

GitLab объявила 17 сентября, что перестраивает лимиты запросов на GitLab.com: вместо единой планки для всех появляются квоты, привязанные к тарифу. Самое громкое число в анонсе — 60 запросов в час на один IP-адрес для неавторизованного трафика. Сейчас там действует 500 запросов в минуту. Для бесплатных аккаунтов и запросов без токена новые правила включаются 19 октября 2026 года, для Premium и Ultimate — в январе 2027-го. Перед этим, 7 и 14 октября, GitLab проведёт два «brownout»-окна, когда лимиты включат на четыре часа — чтобы все успели увидеть, что у них сломается.

Изменение касается только облачного GitLab.com. Self-managed и GitLab Dedicated его не затрагивают — там лимиты по-прежнему настраивает администратор инстанса.

Что именно меняется: часовая квота вместо «запросов в минуту»

Сегодня лимиты на GitLab.com привязаны не к подписке, а к типу трафика. Основные действующие значения такие:

• авторизованный API — 2 000 запросов в минуту на пользователя;
• авторизованный не-API HTTP (веб-интерфейс) — 1 000 в минуту;
• неавторизованный трафик — 500 в минуту на IP;
• авторизованный Git по HTTPS — 10 000 в минуту;
• плюс точечные ограничения: создание issue — 200 в минуту, создание пайплайна — 25 в минуту на связку «проект + пользователь + коммит».

Новая схема добавляет поверх этого два уровня — sustained (устойчивый, часовой) и burst (пиковый, минутный), и оба теперь зависят от тарифа. Считаются они на пользователя и на top-level-группу, то есть на корневую группу всего вашего пространства проектов.

Новые лимиты по тарифам

• Free — 5 000 запросов в час, пик 100 в минуту.
• Premium — 15 000 в час, пик 1 250 в минуту.
• Ultimate — 25 000 в час, пик 2 000 в минуту.
• Без авторизации — 60 запросов в час на IP, на любом тарифе.

Новые квоты распространяются на запросы к API, обычные веб-запросы и авторизованные операции Git по HTTPS. Отдельно стоит запомнить правило из документации: если к запросу применимы и старый, и новый лимит, срабатывает более строгий из них. Новая схема ничего не отменяет — она добавляется к тому, что уже есть.

И ещё одна деталь, которую легко пропустить. Минутный «пик» — это не разрешённая скорость работы, а именно запас на короткие всплески. GitLab приводит собственный расчёт: если долбить API ровно на уровне минутного лимита, часовая квота закончится примерно за 50 минут на Free, за 12 минут на Premium и за 12,5 минут на Ultimate. После этого — 429 до конца часа.

Почему 60 запросов в час — это болезненнее, чем выглядит

Падение с 500 запросов в минуту до 60 в час — это сокращение потолка примерно в 500 раз. И цифра эта не случайная: ровно 60 неавторизованных запросов в час на IP много лет держит REST API GitHub. GitLab, по сути, приводит облако к той же норме, которая давно стала отраслевой для публичных API.

Проблема в том, что неавторизованные запросы редко делает человек — их делают вещи, о которых уже забыли, что они существуют:

• скрипты и curl в CI, которые тянут информацию о проекте, тегах или последнем релизе без токена, потому что «это же публичный репозиторий»;
• сборка документации и генераторы статических сайтов, подтягивающие список релизов, контрибьюторов или содержимое файлов на каждом билде;
• самодельные бейджи, дашборды и мониторинги, опрашивающие API по расписанию;
• зеркала, боты и интеграции, поднятые когда-то «на посмотреть» и с тех пор работающие сами;
• ИИ-агенты, которые ходят в публичный API за кодом и обсуждениями — их GitLab упоминает в анонсе прямо.

Отдельный нюанс корпоративных сетей: неавторизованный лимит считается на IP. Если офис или CI-раннеры выходят в интернет через один NAT, эти 60 запросов в час вы делите со всеми коллегами и всеми задачами сразу.

Календарь: когда что включится

• 7 октября 2026, 15:00–19:00 UTC — первое brownout-окно: лимиты включают временно.
• 14 октября 2026, 15:00–19:00 UTC — второе окно.
• 19 октября 2026 — постоянное включение для Free и неавторизованного трафика.
• январь 2027 — включение для Premium и Ultimate.

Brownout-окна здесь — главный практический подарок. Это единственная возможность увидеть свои 429 в контролируемых условиях, а не в пятницу вечером посреди релиза. Если у вас есть ночные джобы или регулярные интеграции, имеет смысл заранее прогнать их в эти четыре часа руками.

Зачем это GitLab

Объяснение в анонсе прямое: «Спрос быстро растёт, и мы ожидаем, что нагрузка на платформу вырастет за этот год в несколько раз. Предсказуемые лимиты — это то, что сохраняет GitLab.com быстрым для всех, кто на нём работает, включая те самые автоматизации и агентские нагрузки, которые команды сейчас строят».

Иными словами, платформа расплачивается за собственный успех в автоматизации: ИИ-агент, который вместо одного разработчика делает сотни запросов подряд, для инфраструктуры выглядит как DDoS с легитимным токеном. Тарифные квоты — способ сделать эту нагрузку счётной.

Компания при этом успокаивает: «Почти все пользователи уже находятся внутри новых лимитов и не заметят никаких изменений». Это, скорее всего, правда — но с важной оговоркой: те, кто не внутри, это как раз команды с плотным CI, интеграциями и ботами. То есть техническая аудитория, которой и придётся что-то править.

Что делать: короткий чек-лист

1. Добавить авторизацию везде, где её нет

Это самое дешёвое действие с самым большим эффектом: переход с неавторизованных запросов на авторизованные поднимает потолок с 60 запросов в час до 5 000 даже на бесплатном тарифе — более чем в 80 раз, без оплаты. Подойдёт любой из трёх вариантов: personal access token (персональный токен доступа), OAuth-токен или CI/CD job token — токен, который GitLab сам выдаёт каждой задаче пайплайна.

В пайплайне последнее не требует вообще никакой настройки — переменная уже есть:

curl --header "JOB-TOKEN: $CI_JOB_TOKEN" \
  "https://gitlab.com/api/v4/projects/$CI_PROJECT_ID/releases"

2. Найти безтокенные вызовы

Пройдитесь поиском по .gitlab-ci.yml, скриптам сборки, Dockerfile и служебным утилитам: любой curl или HTTP-клиент, обращающийся к gitlab.com/api/v4 без заголовка с токеном, — кандидат на поломку 19 октября. Отдельно проверьте зависимости и плагины, которые ходят в API за вас.

3. Научить клиенты читать ответ

При превышении GitLab отдаёт 429 Too Many Requests с заголовками RateLimit-Limit, RateLimit-Remaining, RateLimit-ResetTime и Retry-After. Как формулирует сам GitLab, клиент, который читает свои же заголовки ответа, в основном исправляет себя сам: ждёт указанное время и повторяет запрос вместо того, чтобы биться в стену.

Важная ловушка: у API проектов, групп и пользователей информационные заголовки в ответах о превышении лимита не приходят. Там ориентироваться придётся на сам код 429 и собственный backoff (постепенное увеличение паузы между повторами).

4. Перестать опрашивать по кругу

Polling — главный пожиратель квоты. Там, где нужно узнавать о событиях, вебхуки почти всегда дешевле: у них собственные, куда более щедрые лимиты — 500 вызовов в минуту на Free, 1 600 на Premium (до 99 мест) и 6 000 на Ultimate (до 999 мест). Плюс обычная гигиена: кешировать ответы, запрашивать страницами побольше, не дёргать один и тот же эндпоинт из нескольких джоб одновременно.

5. Не сваливать всю автоматизацию на один аккаунт

Поскольку лимит считается на пользователя и на корневую группу, а не на токен, один «сервисный» аккаунт, под которым работают все боты и интеграции, превращается в узкое горлышко: его 5 000 или 15 000 запросов в час делят между собой все ваши процессы разом. Развести нагрузку по разным учётным записям стоит до октября, а не после первого инцидента.

Более широкая картина

Эпоха, когда публичный API любого крупного сервиса можно было дёргать анонимно и почти бесконечно, заканчивается — и заканчивается по конкретной причине. Массовый скрейпинг для обучения моделей и автономные агенты, каждый из которых генерирует трафик за десяток разработчиков, сделали анонимный доступ слишком дорогим для платформ. GitLab здесь не первый и точно не последний: 60 запросов в час — это не наказание, а новая отраслевая норма, к которой стоит привыкнуть заранее.

Практический вывод для команд простой: токен в каждом запросе, обработка 429 в каждом клиенте, вебхуки вместо опроса. Всё это — работа на день, но сделать её лучше до 7 октября, когда brownout-окно покажет вашу автоматизацию такой, какой она станет 19-го.