GitLab：429「Retry later」— 回数の上限を超えた
リクエストが回数の上限を超えると、GitLab は 429 Too Many Requests を返します。送り直す前に待ちます。Retry-After の見出しが、上限が戻るまでの秒数です（GitLab の説明「GitLab.com の回数の上限」・2026年10月28日に確認）。GitLab の上限は2種類あり、答え方が違います：
HTTP/1.1 429 Too Many Requests
Content-Type: text/plain
Retry-After: 30
RateLimit-Name: throttle_authenticated_api
Retry later
HTTP/1.1 429 Too Many Requests
RateLimit-Name: notes_create
{"message":{"error":"This endpoint has been requested too many times. Try again later."}}
2種類の上限
- すべてのリクエストの上限（Rack::Attack・HTTP の層）：たとえば、ユーザーごとのトークン付きの API のリクエストや、IP アドレスごとのトークンなしのリクエストです。本文はただの文字で、既定は
Retry later（あとでやり直す）です。管理者は Admin の Settings > Network の User and IP rate limits で差し替えられます。この上限は下の RateLimit の見出しに出ます（GitLab の説明「ユーザーと IP の回数の上限」）。 - 1つの操作の上限（アプリケーションの回数の上限）：たとえば、イシューの作成や、イシューとマージリクエストへのコメント（ノート）の作成です。本文は JSON で、
message.errorに「This endpoint has been requested too many times. Try again later.」（この窓口は呼ばれすぎた。あとでやり直す）、RateLimit-Nameに上限の名前、Retry-Afterにその上限の時間の幅が入ります。この上限は RateLimit の見出しに出ないので、前の答えで残りがあっても 429 になることがあります（GitLab のソースlib/api/helpers/rate_limiter.rbとlib/gitlab/application_rate_limiter.rb・2026年10月28日に読んだもの）。
見出し
- どの答えにも（1つ目の種類の上限）：
RateLimit-Limit（1分あたりの上限）、RateLimit-Name（throttle_authenticated_apiのような上限の名前）、RateLimit-Observed（その時間の幅のリクエストの数）、RateLimit-Remaining（残り）、RateLimit-Reset（上限が戻る Unix 時刻）。出るのは、この種類の上限のうちいちばん厳しいものだけです。 - 429 のとき：さらに
Retry-After（上限が戻るまでの秒数）とRateLimit-ResetTime（同じことを日時で）。GitLab は今の時間の幅の終わりまでの秒数を数えるので、1時間ごとの上限なら最大1時間待つように言われます（GitLab のソースlib/gitlab/rack_attack/request_throttle_data.rb）。 - 出ない所：GitLab.com では、Projects・Groups・Users の API の 429 にはこれらの見出しが付きません。
GitLab.com：今の上限
- ユーザーごとのトークン付きの API のリクエスト：1分に 2,000。
- IP アドレスごとのトークンなしのリクエスト：1分に 500。IP アドレスごとのすべてのリクエスト：1分に 2,000。
- イシューとマージリクエストへのコメント：1分に 60。プロジェクト・ユーザー・コミットごとのパイプラインの作成：1分に 25。
/api/v4/users/:idへの API のリクエスト：10分に 300。検索の API：1分に 100。
GitLab はプランごとの上限も提案しています。まだ効いておらず、日付は前もって知らされ、効く前に短い試しの時間（brownout）があります。ユーザーごとのトークン付きのリクエストは1時間に Free で 5,000・Premium で 15,000・Ultimate で 25,000、ほかに1分ごとの瞬間の上限（Free の API は 100）。IP アドレスごとのトークンなしのリクエストは1時間に 60 です。両方が当てはまるときは、低い方が効きます。
GitLab Self-Managed
API と画面のリクエストのユーザーと IP の回数の上限は、トークンの有無にかかわらず、既定では切れています。管理者が Admin の Settings > Network の User and IP rate limits で入れて決めます。コメントの作成の上限は既定で入っていて、ユーザーごとに1分に 300、除くユーザーの一覧があります（コメントの作成）。
直す所
- Retry-After の秒数だけ待ってからやり直し、まだ 429 なら間をさらに空けます。
- トークンを使う：トークンなしのリクエストは上限がいちばん低く、IP アドレスごとに、そのアドレスのほかのリクエストと合わせて数えられます。
- リクエストを減らす：
RateLimit-Remainingを見て、答えを取っておき、一覧は全部を読み直さずページで送り、何度も問い合わせるスクリプトは間を空けます。 - 自分のインスタンスなら：管理者が上限を上げるか、コメントの作成の上限からユーザーを除けます。
IntelliJ IDEA で GitLab のマージリクエストとパイプラインを扱うなら
Lesstep は、JetBrains IDE（2024.1 以降）のプラグインを2つ作っています。Merge Request Inbox for GitLab と Pipeline Inbox for GitLab CI です。GitLab が 429 を返すと、GitLab の呼び出し回数の上限に達したこと、1分ほど待ってから読み直すように言います。Merge Request Inbox 1.0.19・Pipeline Inbox 1.0.21 からは、Retry-After が1分より長いときは、代わりにまた使えるようになる時刻を言います。トークンなしなら、設定で個人アクセストークンを入れるように勧めます（読むのは無料のまま）。読むのは無料、承認・コメント・マージや、パイプラインの再実行・取り消し・実行は Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。
GITLAB は GitLab Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitLab Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：GitLab の 401「invalid_token」 · GitLab の「insufficient_scope」 · GitLab の 404「Project Not Found」 · GitLab のコメント・スレッドの断り（400・403） · GitLab の MR の一覧の断り（400・404） · GitLab のパイプラインやジョブの断り（400・403・409・429） · GitLab の「compare_timeout」（差分の上限） · JetBrains の IDE で GitLab のマージリクエストを扱う · JetBrains の IDE で GitLab のパイプラインを扱う · English