Cloudflare 1102/503の最初の30分でやること
Cloudflare Worker(OpenNext)で503/1102が出たときに、最初の30分で止血する切り分け順です。
Cloudflare Worker（OpenNext含む）運用でしんどいのは、「検索が急落した」「収益が落ちた」という“結果”から入ると、復旧が遅れることです。先にやるべきなのは、ユーザー（とGooglebot）が到達できない状態（503/1102/タイムアウト）を、短時間で切り分けて“止血”することです。
この記事は、Cloudflare側のエラー（例: 1102）や503が出たときに、最初の30分でやることを固定するためのチェックリストです。原因の推理より、復旧を早める順番を優先します。
0. まずやらないこと
- いきなり大きくリファクタする
- 依存を一斉更新する
- ルーティングやmiddlewareを触り散らかす
- 「たぶんここが悪い」で本番に連続デプロイする
障害時は、まず「どこで落ちているか」を絞り、再現性のある観測点を作るのが先です。
1. 影響範囲を3つに分ける（最優先）
最初に“全部”を見ないで、影響範囲を固定します。
- すべてのページが落ちている（トップも含めて503/1102）
- 一部のページだけ落ちている（特定のルート・動的ルート）
- 特定のUAだけ落ちている（Googlebotや特定地域など）
これが分かると、見るべきログ/設定/コードの場所が一気に減ります。
関連: /media/search-console-drop-first-30-minutes
2. まずは「重要URLを5つ」だけ直叩きする
ブラウザで見る前に、最低限の5URLだけ決めて直叩きします（ページは例です）。
/（トップ）/pricing（料金）/dashboard（ログイン後導線）/api/health（もしあるなら）robots.txt/sitemap.xml（SEO入口）
ここで「どれが落ちるか」をメモして、次の切り分けに使います。
3. 503/1102のときに、最初に疑う順番（速い）
A. 直近デプロイに紐づくもの（最速に当たる）
- デプロイ直後から発生したか
- 直前の変更が
middleware/ 認証 / ルーティング / fetch まわりか - ビルド成果物（OpenNext bundle）が生成されているか
B. 設定・制限系（発生が急で、再現が薄いことがある）
- 実行時間・CPU・メモリ系の制限に当たっていないか
- 外部API（Google/Stripe/Tursoなど）への接続で詰まっていないか
- 例外が握り潰されて「同じエラーに見えている」だけではないか
C. ルート依存（“一部だけ落ちる”ならここ）
- 動的ルートでだけ落ちる（DB/外部API/重い処理の可能性）
- 特定のクエリやパラメータで落ちる（入力バリデーション不足）
- 特定のページだけ重い（生成/変換/画像など）
4. “止血”のための暫定措置（やり過ぎない）
復旧を早めるために、一時的にできることはあります。ただし「戻せる形」に限ります。
- エラー発生ルートで重い処理を止めて、軽いフォールバックを返す
- 外部API呼び出しにタイムアウト/リトライ上限を入れる
- 例外時に500で落ちるより、ユーザーに説明した固定ページを返す（公開ページのみ）
目的は“収束”で、恒久対応は次のコミットで丁寧にやります。
5. 収束後にやること（恒久対応の入口）
障害が止まったら、次の「再発防止」に繋げます。
- 再現条件（どのURL/どの条件）を短くメモして残す
- 原因箇所を1つに絞って、最小パッチで直す
- 観測点（エラーの種類、外部依存の失敗、トレース）を追加して“次は見える”状態にする
この順番にすると、「焦って触って悪化する」を避けられます。
この記事を書いた人
川原
SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。
関連記事
次にやること
複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。
料金を見る相談したい / お問い合わせ