GitLab.comへ通常どおりgit pushしたところ、push自体は成功しているのに、remote:から大きなrate-limit変更の案内が表示されることがありました。
remote: Scheduled rate-limit preview window ...
remote: ...
To gitlab.com:example/example.git
old..new main -> main一見すると、無料プランではGit操作が制限される、あるいは有料プランへの移行を求められているようにも見えます。しかし、まず確認すべきなのはpushの成否です。
１、main -> mainまで出ていればpush自体は成功している
最後に次のような表示があれば、コミットはリモートへ正常に送信されています。
main -> mainremote:で始まる文章は、GitLabサーバー側からクライアントへ返された案内です。エラーとは限りません。
２、2026年10月19日からGitLab.comのレート制限が変更された
GitLab.comでは2026年10月19日から、Freeプランと未認証トラフィックを対象に新しいレート制限が適用されました。その前には、新しい制限を一時的に有効にするプレビュー期間も設けられていました。
このため、通常のgit push時にも変更案内がremote:メッセージとして表示される場合があります。
３、通常のSSHによるGit操作とは分けて考える
GitLabにはAPI、HTTP、Git HTTPS、Git SSHなど用途ごとにレート制限があります。Git SSHについても制限値はありますが、一般的な人手によるgit pullやgit pushを数回行う程度と、自動化によって大量のAPIリクエストを送る処理は性質が異なります。
そのため、警告文が出ただけで直ちに有料プランへ変更するのではなく、自分の処理がどの種類のトラフィックに該当するのかを確認することが重要です。
４、自動処理では未認証アクセスを避ける
影響を受けやすいのは、GitLab APIやHTTPエンドポイントを短い間隔で繰り返し呼び出す自動処理です。特に未認証アクセスは、認証済みアクセスより厳しい制限を受ける場合があります。
CI/CDや管理スクリプトでAPIを利用している場合は、Personal Access Token、OAuth、CI/CD Job Tokenなど、用途に合った認証方法を利用しているか確認します。
５、Gitのエラーと運営からの告知を分けて読む
git pushの出力には、転送処理そのものの結果と、ホスティング事業者からの告知が同じremote:形式で混ざって表示されることがあります。
大きな告知が表示されても、最後のref更新結果まで確認すれば、pushが成功したのか失敗したのかを落ち着いて判断できます。
Gitホスティングサービスの仕様変更は今後もあり得ます。通常運用では必要以上に反応せず、自動化や大量アクセスを行う部分だけは公式のレート制限を定期的に確認する、という切り分けが現実的です。