Cronが動かないときの確認方法｜時刻・PATH・ログの失敗例

Cronは、バックアップ、集計、通知などを決まった時刻に実行する仕組みです。設定行が保存できても、時刻の解釈、実行環境、権限、ログ出力のどこかが違うと「手動では動くのにCronでは動かない」状態になります。

ここではCron式ジェネレーターで式を作ったあと、実行前に確認する項目と、失敗したときの切り分け方を具体例で説明します。

Cron式の5項目を読み違えない

# 分 時 日 月 曜日 コマンド
  0  3  *  *  *   /usr/local/bin/php /var/www/job.php

この例は毎日3時00分に実行します。左から「分・時・日・月・曜日」で、秒の欄はありません。サービス独自のCron記法では秒や年を含む場合があるため、登録先の仕様も確認してください。

多くのCron実装では「日」と「曜日」の両方を絞ると、ANDではなくORとして扱われます。例えば「毎月15日が月曜日のときだけ」というつもりでも、毎月15日と毎週月曜日の両方で動く可能性があります。複雑な条件はスクリプト側でも日付を確認する方が安全です。

管理画面が日本語でも、CronがUTCで動く環境があります。日本時間21時に実行したいのにUTC 21時で登録すると、実際には翌朝6時に動きます。サーバー時刻と、利用サービスが指定するタイムゾーンを先に確認してください。

Cronは、普段ログインして使うシェルと同じ環境では動きません。phpやnodeが見つからず、相対パスで指定した設定ファイルも読めないことがあります。

0 3 * * * cd /var/www/app && /usr/local/bin/php scripts/job.php

確認方法：実行ファイルとスクリプトを絶対パスで指定し、必要なら cd で作業ディレクトリを明示します。秘密情報をコマンドへ直接書かず、権限を制限した設定ファイルから読み込みます。

手動確認では自分のアカウント、CronではWebサーバー用アカウントというように、実行ユーザーが異なる場合があります。読み込むファイル、書き込み先、秘密鍵にそのユーザーがアクセスできるか確認してください。

権限エラーを避けるために無条件で広い権限を付けるのではなく、必要なディレクトリだけへ最小限の権限を設定します。出力先が存在し、ディスク容量が残っていることも確認します。

画面のないCronでは、ログがなければ「起動していない」のか「起動後に失敗した」のか判断できません。まず検証用のログへ標準出力と標準エラーをまとめます。

0 3 * * * /usr/local/bin/php /var/www/app/job.php \
  >> /var/www/app/logs/job.log 2>&1

ログが増え続けないよう、保存期間やローテーションも決めます。動作確認後も、開始時刻、終了、処理件数、終了コードを残すと障害調査が容易になります。

検証中の毎分実行を戻し忘れると、重複処理やAPI制限の原因になります。同じ処理が重なっても壊れない設計や、ロックファイルによる多重起動防止も検討してください。

Cron式が正しいだけでは、定期処理の成功は保証されません。式を生成したら、タイムゾーン、実行ユーザー、PATH、権限、ログの順に確認します。最初は副作用のないテスト処理で実行時刻を確かめてから、本番のコマンドへ切り替えてください。