cronが動かない時のチェックリスト｜原因の切り分けと確認手順

最終更新: 2026-07-19

cronで設定したはずのジョブが動かない——これは非常によくあるトラブルです。原因の多くは「cron式の間違い」ではなく「実行環境の違い」にあります。この記事では、あわてて設定を書き換える前に確認すべきポイントを、切り分けやすい順番で紹介します。

まず切り分ける3つの可能性

1. そもそもcronが起動していない（サービス停止）
2. スケジュール(cron式)が意図とずれている（時刻・曜日・タイムゾーン）
3. ジョブは起動しているがコマンドが失敗している（PATH・権限・パス違い）

このうち3番目が最頻です。「cronの画面上は正しそうなのに動かない」ケースはほぼコマンド側の問題だと考えて調べ始めると早く解決します。

cron式が意図どおりか確認する

まず式の解釈を客観的に確認しましょう。頭の中の想定と、cronの実際の解釈がずれていることがあります。当サイトのcron式 変換・解説ツールに式を貼ると、日本語での意味と「次に実行される時刻」が確認できます。とくに*/15のような間隔指定や、日と曜日の同時指定は勘違いが起きやすいポイントです。

ログを確認する（動いた形跡があるか）

cronの実行ログを見れば「起動すらしていない」のか「起動したが失敗した」のかが分かります。ディストリビューションによって場所が異なります。

# Debian/Ubuntu 系
grep CRON /var/log/syslog

# RHEL/CentOS 系
sudo cat /var/log/cron

# systemd 環境
journalctl -u cron    # または -u crond

ログにジョブの起動記録がなければ、cron式の時刻がまだ来ていないか、cronサービス自体が止まっている可能性が高いです。systemctl status cron（またはcrond）でサービスの稼働を確認します。

PATH・環境変数の罠（最頻の原因）

cronは、あなたが手動でログインした時とは異なる最小限の環境でコマンドを実行します。ターミナルでは動くのにcronでは失敗する、の典型がこれです。とくにPATHが短いため、nodeやpythonなどをコマンド名だけで呼ぶと「見つからない」で失敗します。

• コマンドは絶対パスで書く（例: /usr/bin/python3）。which python3で確認できます。
• スクリプト冒頭で必要な環境変数を明示的に読み込む（source ~/.bashrc 等は効かないことがあるため、必要な変数を直接設定）。
• 出力を必ずファイルにリダイレクトしてエラーを残す: * * * * * /path/to/job.sh >> /tmp/job.log 2>&1

「原因が分からない」時は、まず上記のリダイレクトを付けてログを取るのが近道です。エラーメッセージさえ取れれば、あとは通常のシェルスクリプトのデバッグと同じです。

やりがちな事故: crontab -r

crontab -e（編集）とcrontab -r（全削除）はキーが隣同士で、押し間違いでcron設定を全消ししてしまう事故が定番です。編集前にcrontab -l > ~/crontab.bakでバックアップを取る習慣をつけておくと安全です。

※ クラウドのcron（GitHub Actions・Vercel等）はここで挙げたサーバー系の確認方法とは事情が異なります。多くはタイムゾーンがUTCで、実行の遅延・スキップも起こります。詳しくは各プラットフォームのガイドを参照してください。