Cloudflare WorkersのCronが動かないとき、最初の30分でやること

Cloudflare WorkersのCron（Cron Triggers / Scheduled Event）が「動いていない」「急に止まった」ように見えるときは、まず“実行されていない”のか、“実行されたが途中で失敗している”のかを切り分けるのが最短です。

この記事は、Cloudflare Workersで定期ジョブが動かないとき、最初の30分で“止血”するためのチェックリストです。

関連:

• /media/cloudflare-deploy-not-reflected-first-30-minutes
• /media/search-console-server-error-5xx-first-30-minutes

0. まず結論（先にやる順番）

最初の30分は、原因推理より 証拠で固定 します。

1. 「実行されていない」vs「実行されたが失敗」 をログで確定する
2. 対象のWorker/環境/アカウント取り違え を潰す（本番/プレビュー）
3. Cron設定の存在（トリガーが付いているか）を確認する
4. 直近の変更（デプロイ/環境変数/ルート/依存） で壊れていないか当たりを付ける
5. 復旧後に 再発防止（観測点/冪等性/アラート） を入れる（30分の外）

1. まず“止まったように見える”の定義を固定する（最優先）

次のどれが起きていますか？ここを曖昧にすると遠回りになります。

• ジョブが起動していない（ログが一切増えない）
• 起動はしているが失敗している（例外/タイムアウト/外部API失敗）
• 起動しているが処理結果が反映されない（DB/キャッシュ/後続パイプラインで詰まり）
• 起動しているが二重実行/重複実行で壊れている（冪等性不足）

最初に取るべき証拠:

• Cloudflare側の 実行ログ（リクエストログではなく、ジョブ実行のログ/例外）
• 可能なら、ジョブの最初に出す 固定ログ（cron_start など）

2. 取り違え（本番/別環境/別アカウント）を潰す

“動いていない”事故の一定割合は取り違えです。

• 対象が 本番のWorker か（同名Workerや別プロジェクト混在に注意）
• 環境（production / preview） の取り違えがないか
• スケジュールを付けたのが 別のWorker になっていないか
• 直近のデプロイが本番に載っているか（反映の確認）

3. Cron設定そのものが存在するか（最短チェック）

Cronが動かないときは、まず トリガーが付いているか を確認します。

チェック観点:

• Cron Triggers（スケジュール）が 有効 になっているか
• スケジュールが 意図した頻度 か（分/時/日）
• 直近で 設定を触っていないつもりでも、プロジェクト切替や再作成で外れていないか

4. “実行はされているが失敗”の典型パターン（30分で当てにいく）

ログで「起動している」ことが分かったら、次を上から潰します。

4-1. 実行時間・CPU制限・外部I/O待ち

• 外部APIが遅い/落ちている（DNS/タイムアウト/レート制限）
• 1回の実行でやることが多すぎる（バッチ化が必要）
• 重い処理を同期でやっている（分割・Queue化・リトライ方針が必要）

最初の30分の止血としては:

• 一時的に 処理対象を絞る（直近n件だけ、差分だけ）
• 外部I/Oは タイムアウト短め + リトライ方針を明示（無限待ちを避ける）

4-2. 環境変数・バインディングの欠落

「ローカル/プレビューでは動くのに本番だけ落ちる」の典型です。

• 本番環境に必要な 環境変数が入っているか
• KV/D1/R2/Queues/Service bindings などの バインディングが本番に存在 するか
• “名前だけ同じで中身が違う”ケース（別環境のKVを参照している等）

4-3. エラーは出ているが“通知されない”

失敗しているのに気づけない状態だと、復旧しても再発します。

• ジョブ開始/終了/失敗を、最低限 1行ログ で必ず出す
• 失敗時だけでも 通知（メール/Slack等）に落とす（再発防止）

5. “実行されていない”ときの典型パターン（取りこぼしやすい）

5-1. トリガーが外れている / 無効になっている

一番多いです。まずここを疑います。

5-2. デプロイでWorkerが差し替わり、トリガーが期待どおり引き継がれていない

手元の設定とCloudflare側の状態がずれると、「あるはずのCronがない」状態になります。

止血:

• まずCloudflare側で トリガー有無を再確認
• 必要なら 最小頻度（例: 1時間ごと） で一度付け直し、ログで起動を確認

5-3. 実行されているが“結果の反映先”が違う

例えば、ジョブは走っているのに「DB/ストレージ/キャッシュ」が別環境を向いていると、見た目は止まります。

• 書き込み先（DB/KV/R2）をログに出して どこに書いているか を確定する

6. 再発防止（30分の外）

復旧したあとに、次だけは入れておくと“止まった”が即分かります。

• 起動ログ + 終了ログ + 失敗ログ（3点セット）
• 冪等性（同じ実行が2回走っても壊れない）
• 観測点（最終成功時刻の記録と可視化）
• 通知（最後の成功から一定時間経過でアラート）

SiteOpsで“定期ジョブ停止”を早期検知する

Cron停止は、気づくのが遅いほど機会損失が増えます。再発防止としては「最後に成功した時刻」と「失敗の兆候」を誰でも同じ根拠で見られる状態に寄せるのが効きます。

• “最終成功時刻”が見える（ダッシュボード/通知）
• 失敗時のログが揃っていて、最初の30分で切り分けられる

状況が複合している/再現しない場合は、相談だけ先に進めるのも有効です。

• 料金・導入の概要を見る
• 相談する

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること障害対応更新: 2026-05-18

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ