ひとことで言うと
Cloudflareダッシュボード → Pages → プロジェクト → Settings → Git repository → Manage を開き、GitHubインテグレーションを再インストールする。ほとんどのケースはこれで2分以内に解決する。
再認証後は空コミットで強制デプロイ:
git commit --allow-empty -m "force deploy after reconnect"
git push
再認証しただけでは過去のコミットがデプロイされない。この空コミットpushを忘れると「再認証したのに変わらない」という状況になる。
やりたかったこと
2ヶ月ぶりにAstroサイトを更新しようと記事を1本書いてgit pushした。GitHubのリポジトリにはちゃんとコミットが積まれているのに、5分待っても10分待っても Cloudflare PagesのDeploymentsタブに何も来なかった。
おかしいと思ってプロジェクトのトップを開いたら、薄いオレンジのバナーが出ていた。
Cloudflare Pagesが表示するバナーには以下の6種類がある:
This project is disconnected from your Git account, this may cause deployments to fail.Cloudflare Pages is not properly installed on your Git account, this may cause deployments to fail.The Cloudflare Pages installation has been suspended, this may cause deployments to fail.The project is linked to a repository that no longer exists, this may cause deployments to fail.The repository cannot be accessed, this may cause deployments to fail.There is an internal issue with your Cloudflare Pages Git installation.
今回出ていたのは最初のメッセージだった:
This project is disconnected from your Git account.
This may cause deployments to fail.
「May cause」という書き方だったので最初は軽く見ていた。だけど実際にはこのバナーが出ている状態ではpushを検知すらしていなくて、バナーを出してから30分以上放置してしまった。
Deploymentsタブを開いて確認したら、最後のデプロイは2ヶ月前のままで、その後のコミットは全部ゼロ。失敗しているわけでもなく、ビルド自体が来ていない状態だった。つまり2ヶ月分の記事追加が全部公開されていなかったことになる。
環境
- Cloudflare Pages(2026年5月時点)
- GitHub
- Astro 5.2.3
- Node.js 20.11.0
- Windows 11
試したこと・うまくいかなかったこと
ブラウザのキャッシュ疑い → 関係なかった
最初はCloudflareダッシュボードをCtrl+Shift+Rでハードリロードしてみた。バナーは消えなかった。次に「Retry deployment」ボタンを探したが、そもそもDeploymentsタブに新しいビルドが来ていないのでRetryする対象自体がなかった。最後のビルドエントリの「…」メニューを開いたら「Retry deployment」はグレーアウトして押せない状態だった。「ビルドが失敗しているなら再試行できるはず」と思い込んでいたが、ビルドが来ていない状態ではRetryの概念自体が成立しないことを理解した。
git push再実行 → 全く反応なし
「もう一度pushすれば直るかも」と思って git push、さらに git push --force まで試したが、GitHubのリポジトリには正しくコミットが積まれているのにCloudflareは無反応のままだった。GitHubとCloudflareの間の接続が切れているのだから、どんな形でpushしてもCloudflareには届かない。
Cloudflareのサービス障害を疑った → Operational だった
cloudflarestatus.com を開いてシステム障害を確認した。すべてOperationalで、自分のアカウントだけの問題だとわかった。
その後、GitHubのWebhookのdeliveryログを確認したら、最新エントリのレスポンスが 401 Unauthorized になっていた。
POST https://api.cloudflare.com/client/v4/pages/webhooks/deploy/...
HTTP/2 401
{"result":null,"success":false,"errors":[{"code":10000,"message":"Authentication error"}],"messages":[]}
これでOAuthトークンの有効期限が切れているのが確定した。
「Installed GitHub Apps」タブを確認したが → OAuth Appsと別物だった
GitHubのSettings → Applications の「Installed GitHub Apps」タブを確認して「Cloudflareのエントリがある、大丈夫だ」と思ってしまった。実はここはGitHub Apps用のリストで、Cloudflare PagesはOAuth Apps(「Authorized OAuth Apps」タブの方)を使う。この2つのリストを混同して原因の切り分けに30分以上かかった。
Authorized OAuth Appsタブを開いたら、Cloudflare Pagesのエントリが「Revoked」になっていた。ここで確定した。
解決策
根本原因
GitHubのOAuthトークンが失効していた。GitHubのセキュリティ設定変更(2FA変更・パスワード変更など)後にOAuthアプリの認可がリセットされるケースがある。自分がGitHubのセキュリティ設定を触った日とデプロイが止まった日が一致していた。
1. GitHubを再認証する
Cloudflareダッシュボードで該当プロジェクトを開き、「Settings」タブ(上部のタブ、左サイドバーではない)→「Git repository」セクションの「Manage」をクリックする。GitHubのOAuth認証画面が開くので「Authorize Cloudflare Pages」で認証する。
認証後、GitHubのWebhooks画面の「Ping」ボタンを押してその場で疎通確認できる。Pingのレスポンスが200なら再認証成功、401ならまだ切れている。
# GitHubのWebhookページでPingを送る
リポジトリ → Settings → Webhooks → 対象Webhook → Recent Deliveries → Ping
2. 空のコミットで強制デプロイ
再認証しただけでは過去のコミットが遡ってデプロイされない。認証が切れていた間のコミットはCloudflareが受け取っていないので、空コミットをpushして強制的にトリガーする。
git commit --allow-empty -m "force deploy"
git push
pushから1〜2分でDeploymentsタブに新しいビルドが来て、最新コミットの状態でデプロイされる。切断期間中の記事はこの1回のデプロイでまとめて公開される。
3. GitHubのWebhookをリデリバリする(補足)
GitHubのSettings → Webhooks → 対象のWebhook → 「Recent Deliveries」タブから、失敗しているdeliveryを「Redeliver」で再送できる。ただし再認証してから実行しないと401で再び失敗する。失敗件数が多い時は空コミットpushの方が早い。
4. 再認証できない場合の対処
「Manage」を押しても認証画面が開かない場合は、Cloudflareのプロジェクト設定から「Disconnect Git repository」で完全に切断し、「Connect to Git」から接続し直す。ブランチ設定などが初期化されるので、接続後に再設定が必要。
Organizationのリポジトリを使っている場合、Organization側のThird-party Access設定でCloudflare Pagesが「Approved」になっているか別途確認が必要。Organizationオーナーでない場合はオーナーに承認を依頼する。
5. 再発防止のポイント
GitHubのセキュリティ設定を変えた後は、Cloudflare PagesのDeploymentsタブで次のpushが正常にビルドされるか確認する習慣をつける。月に1回は「最新のデプロイがいつか」を確認するだけでも、今回のような2ヶ月放置は防げる。
Cloudflareには「Workers & Pages」→プロジェクト→「Settings」→「Notifications」でビルド失敗のメール通知を設定できる。「接続切断」の検知には使えないが、ビルド失敗の早期発見に役立つ。
6. 再接続後のチェックリスト
- Deploymentsタブにビルドが来ているか(空コミットpushから1〜2分後)
- ビルドが「Success」になっているか
- 本番サイトが最新の内容になっているか(シークレットモードで確認)
- GitHubのWebhook deliveryが200を返しているか
- GitHubのAuthorized OAuth AppsにCloudflareが「Revoked」でなく表示されているか
エラーメッセージ別の対処法
”The Cloudflare Pages installation has been suspended”
GitHubの設定でCloudflare PagesアプリがSuspendされている。
- GitHubのインストール設定を開く
- 個人アカウント:
https://github.com/settings/installations - Organization:
https://github.com/organizations/組織名/settings/installations
- 個人アカウント:
- Cloudflare Pagesの「Configure」をクリック
- ページ下部の「Unsuspend」をクリック
”The repository cannot be accessed”
GitHub Appのリポジトリアクセスからこのリポジトリがはずれている。
- 上記のインストール設定を開く
- 「Repository access」で対象リポジトリを追加、または「All repositories」に変更
”The project is linked to a repository that no longer exists”
リポジトリが削除または別アカウントに移管された。
- 削除された場合: 新しいリポジトリで新規Pagesプロジェクトを作成
- 移管された場合: 元のアカウントに戻すか、新しい場所のリポジトリで新規プロジェクトを作成
”There is an internal issue with your Cloudflare Pages Git installation”
Cloudflare内部のエラー。GitHubアプリの再インストールで解消しないならCloudflareサポートに問い合わせる。
ハマったポイント
- バナーが薄いオレンジ色で「May cause deployments to fail」という曖昧な表現だったので最初は軽く見ていた。実際にはその時点でデプロイは完全に止まっていた。バナーの色が薄いから「とりあえず動いているのかも」という思い込みが30分以上の放置につながった。バナーが出た瞬間に対処するのが正解だった
- GitHubのSettings → Applicationsには「Installed GitHub Apps」と「Authorized OAuth Apps」の2つのタブがある。「Installed GitHub Apps」にCloudflareのエントリがあるから大丈夫と思ったが、Cloudflare PagesはOAuth Apps側を使う。全然別のリストだとわかるまで20分以上かかった。「Authorized OAuth Apps」タブで「Revoked」になっているかを確認するのが正しかった
- 再認証しただけで「あとは待てばいい」と思っていたが、認証が切れていた間のコミットはCloudflareが受け取っていないので遡って処理してくれない。空コミットの
git pushが別途必要だと気づくまで20分待ち続けた - 「ビルドが来ない」のと「ビルドが来るが失敗する」は全く別の問題。Deploymentsタブを最初に確認して「Failedが来ているか、それとも何も来ていないか」を確認するだけで診断の入口が決まる。何も来ていない場合はOAuth切断かブランチ設定の問題を疑う
- GitHubのWebhook画面の「Ping」ボタンで、その場で接続が復旧しているか確認できる。再認証後にPingを送って200が返れば完了、401なら再認証が不完全。Deliveryの一覧を眺めるより、このPingで確認する方が30秒で終わる
よくある質問
Q: なぜCloudflare PagesがGitHubと切断されるのか? 最も多い原因はOAuthトークンの有効期限切れ。GitHubの2FA設定変更やパスワード変更後に失効することがある。GitHub側でOAuthアプリへのアクセス許可を手動で取り消した場合も同様。
Q: Cloudflare PagesをGitHubに再接続する方法は? Cloudflareダッシュボード → プロジェクト → Settings → Git repository → Manage → GitHubのOAuth認証画面で「Authorize Cloudflare Pages」を選ぶ。それでもダメなら「Disconnect Git repository」で完全に切断してから「Connect to Git」で接続し直す。
Q: 再接続後もgit pushがデプロイをトリガーしない。
空コミットで強制トリガーする: git commit --allow-empty -m "reconnect" && git push。それでもダメならSettings内のプロダクションブランチ名が実際の作業ブランチと一致しているか確認する。
Q: GitLabでも同じ手順で直る?
はい。再接続手順は同じ。GitLabのインストール設定は https://gitlab.com/-/profile/applications で確認できる。
Q: 接続切断を事前に通知してもらえますか? できない。Cloudflareのビルド失敗通知は設定できるが、OAuth切断の通知機能はない。定期的にDeploymentsタブで最新のデプロイ日時を確認する習慣が唯一の予防策だった。
デプロイが反映されない時はまずDeploymentsタブのログを確認する。ビルドログの見方についてはCloudflare Pagesのビルドログの見方とエラーの対処法が参考になる。
関連記事
- Cloudflare PagesのGitHub自動デプロイが動かない時の対処法
- Cloudflare Pagesのビルドログの見方とエラーの対処法
- AstroをCloudflare Pagesにデプロイする手順
- XserverドメインをCloudflare Pagesのカスタムドメインに設定する全手順
ドメイン取得はこちら
Cloudflareと組み合わせるドメインの取得に。