Vercel Cron Jobが動かないときは、設定がproduction deploymentへ反映されたか、UTCの予定時刻を過ぎたか、要求したpathがredirectや認証で止まっていないかを分けて確認します。手元のブラウザーでendpointを開けたことだけでは、Vercelの定期呼出が成功する証拠になりません。
本稿ではCron作成、endpointへの要求、secret登録、deployment、実データ処理は行っていません。時刻と状態の表は架空例です。自動実行の修復を実測した記事ではありません。
目次
productionへ反映された設定から確認する
Cron Jobsの公式概要（新しいタブで開く）は、設定pathに対してprojectのproduction deployment URLへHTTP GETを送ると説明しています。Previewにcodeがあることや、ローカルに設定ファイルを保存したことと、productionで有効な定期実行を区別します。
projectのCron Jobs画面、現在のproduction deployment、設定に含まれるpathとschedule、無効化の状態を確認します。管理資料（新しいタブで開く）では、設定更新にredeployが必要と案内されています。設定を直す場合も、調査中に本番へ即deploymentせず、変更差分と運用手順を準備します。
表は横にスクロールできます
| 確認対象 | 記録するもの | それだけでは不足すること |
|---|---|---|
| production | deployment ID・反映時刻 | Previewでの成功 |
| 定期設定 | path・schedule・有効状態 | repository内の最新ファイル |
| endpoint | GETの応答と副作用 | browserの最終表示 |
| 処理結果 | 対象期間・処理ID・件数 | HTTP 200だけ |
UTCと契約上の実行精度を分ける
Vercelのcron式のtimezoneはUTCです。日本時間の朝9時なら、同日のUTC 0時に相当します。日付境界や、対象地域が夏時間を使う場合は、業務日付と予定時刻を別に設計します。Cron式の時刻だけを、local timezoneのまま読みません。
管理資料はHobbyでの頻度・時刻精度の制約も説明しています。契約上の許可頻度と、その時刻のどの範囲で起動するかを確認し、指定分の直後にlogがないだけで故障と判断しません。逆に、業務が分単位の期限を必要とするなら、その要件を現行プランで満たすか別に検討します。本稿は課金プランの変更を実施・推奨する判断ではありません。
redirectを自動で追うbrowserと比較しない
Vercel Cronはredirectを追わず、3xxをその呼出の最終応答として扱います。末尾slash、login、別host、localeなどへのredirectがないかを、最初の応答状態とLocationで確認します。browserが追跡した先で200になっていても、Cronが後続の処理へ届いた証拠にはなりません。
予定pathが存在しなければ、定期要求は404になり得ます。認証で401/403になっている場合も、未起動とアプリ内失敗を混ぜません。CRON_SECRETを使う設計では、対象deploymentの設定とAuthorizationの検証処理を確認します。secret値をlogへ出したり、認証を無効化して通す対応は避けます。
logの不在と、処理の不在を分ける
projectとenvironment、予定時刻、requestPathでruntime logを絞ります。redirectやcached responseは通常のlogに出ない場合があると公式管理資料は注意しています。また、配送はbest effortで、要求がFunctionへ届かずlogが作られない場合もあります。履歴がないことだけから、必ず設定ミスだと断定しないようにします。
表は横にスクロールできます
| 観測 | 次に確認 | 原因を隠す対応 |
|---|---|---|
| 3xx | 最初のpathとredirect規則 | browser成功だけで完了 |
| 401/403 | secret・認証条件 | endpointを無認証化 |
| 404 | production出力とpath | scheduleだけ変更 |
| timeout/5xx | 処理段階と上流依存 | 全件を即再実行 |
| 200だが成果なし | 条件・対象期間・処理状態 | 状態だけ監視 |
Cronの実行と、業務上の更新完了を同じ時刻欄にまとめません。処理開始、処理対象の範囲、成功checkpoint、失敗IDが追える設計にします。
再送・重複・抜けを処理できる形で復旧する
公式管理資料は、失敗した呼出の自動再試行をしない一方、同じ予定runが重複配送される場合もあると説明しています。必ず一度だけ起きる前提にせず、最後の成功以降の未処理を照合する設計にします。長い処理では次の起動と重なるため、lockと冪等な更新を別に考えます。
手動実行で埋め合わせる前に、対象期間と処理済みID、外部書込の結果不明な項目を確認します。重複したら金額や回数を足し続ける操作を、HTTPの再要求へそのまま結び付けないようにします。checkpointは予定時刻が来ただけで進めず、対象の処理が確定した範囲で保存します。
変更前のschedule・path・認証条件を残し、検証では定期要求の到達と必要な業務結果を分けて確認します。失敗時は差分を戻しても済んだ外部処理は戻らないため、状態を照合してから再開します。完了記録には、原因を確認できた層、回復した予定run、補完した期間、残った未処理を記録します。