cronの書き方｜設定例30パターンの早見表と落とし穴まとめ

cronは、決めた日時にコマンドを自動で実行するLinuxの仕組みです。設定は crontab -e で開くファイルに「いつ（5つの時刻欄）」と「何を（コマンド）」を1行で書くだけで、バックアップ、ログの整理、定期レポートなどを自動化できます。

書き方自体はシンプルですが、「設定したのに動かない」「思った日と違う日に動いた」というトラブルが非常に多い仕組みでもあります。この記事では、基本の書き方と設定例30パターンの早見表に加えて、ハマりやすい落とし穴、動かないときの確認手順、GitHub ActionsやKubernetesなどcron式の方言の違いまでをまとめました。

cronの基本の書き方

crontabの1行は、5つの時刻欄＋実行するコマンドでできています。

分 時 日 月 曜日 コマンド
*  *  *  *  *   /path/to/command

使える記号

省略形（@で始まる書き方）

設定例30パターン早見表

コピーして、コマンド部分だけ置き換えて使えます。

分・時間ごと

毎日

曜日

月・日

5欄だけでは書けないもの（コマンド側で判定）

末日・第1月曜・最終金曜の例は、GNU版の date を前提にしています（多くのLinuxディストリビューションの標準）。

第1月曜を 0 9 1-7 * 1 と書かないでください。 次の落とし穴で説明するとおり、「1〜7日」または「月曜日」のどちらかに当てはまれば実行されてしまいます。

ハマりやすい落とし穴7つ

1. 日と曜日を両方指定すると「OR条件」になる

もっとも誤解が多い仕様です。

0 9 1-7 * 1

「1〜7日のうちの月曜日（＝第1月曜）」のつもりで書いても、実際は「1〜7日の毎日」と「毎週月曜日」の両方で実行されます。日と曜日の欄が両方とも * 以外のときは、どちらか一方に当てはまれば実行される（OR条件）のが、一般的なcronの仕様です。

「かつ（AND）」にしたいときは、どちらかを * にし、もう一方の条件はコマンド側で判定します（早見表の「第1月曜」の書き方）。

2. % は改行扱いになる

crontabのコマンド部分では、% が改行として扱われます（% 以降は標準入力に渡されます）。日付をファイル名に入れる定番の書き方は、そのままだと動きません。

# ×  % が改行扱いになり、コマンドが途中で切れる
0 3 * * * tar czf /backup/data_$(date +%Y%m%d).tar.gz /data

# ○  % の前に \ を付ける
0 3 * * * tar czf /backup/data_$(date +\%Y\%m\%d).tar.gz /data

3. 手で打つと動くのに、cronだと動かない（PATH）

cronは、ログインしたときとは違う最小限の環境変数でコマンドを実行します。PATHは /usr/bin:/bin 程度しか通っていないことが多く、手で実行すると動くコマンドが「command not found」になります。

対策は次のどちらかです。

• コマンドをフルパスで書く（which コマンド名 でパスを確認）
• crontabの先頭で環境変数を設定する

PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/bash

0 3 * * * backup.sh

同じ理由で、シェルの設定ファイル（.bashrc など）で設定した変数や別名も、cronでは使えません。スクリプトの中で必要な環境を設定するのが確実です。

4. タイムゾーンがずれている

cronは基本的にサーバーのタイムゾーンで動きます。クラウドのサーバーやコンテナは、初期設定がUTC（協定世界時）のことが多く、日本時間の9時のつもりで 0 9 * * * と書くと、日本時間の18時に実行されます。

timedatectl         # サーバーのタイムゾーンを確認
date                # 現在時刻の表示でも確認できる

一部の実装（RHEL系で使われるcronieなど）では、crontabの先頭に CRON_TZ=Asia/Tokyo と書いて、ジョブのタイムゾーンを指定できます。

5. 出力を捨てると、失敗に気づけない

cronは、コマンドの出力をメール（MAILTO宛て）で送ろうとします。メールの設定がないサーバーでは、エラーが誰にも届かず消えていきます。ログファイルに残すのが基本です。

0 3 * * * /home/app/backup.sh >> /var/log/app/backup.log 2>&1

2>&1 で、エラー出力も同じファイルに記録されます。> /dev/null 2>&1 で出力を捨てる書き方もよく見かけますが、失敗に気づけなくなるので、捨てるのは結果を別の方法で監視している場合だけにします。

ログを書き続けるとファイルが大きくなるので、ローテーションもあわせて設定します。消し方を間違えると容量が減らないことがあるので、「Linuxでrmしても容量が減らない原因と対処法」もあわせてどうぞ。

6. 前の実行が終わる前に、次が始まる

5分ごとのジョブが、たまたま6分かかると、同じ処理が2本同時に動きます。データの二重処理や、負荷の急増の原因になります。

flock で、前の実行が終わっていなければスキップさせます。

*/5 * * * * flock -n /tmp/sync.lock /home/app/sync.sh

-n は「ロックが取れなければ待たずに終了する」という意味です。

7. crontab -r で全部消える

crontab -r は、確認なしでその利用者のcrontabをすべて削除します。キーボードで e の隣に r があるため、crontab -e のつもりで打ち間違える事故が起きます。

• 編集前にバックアップを取る習慣をつける：crontab -l > ~/crontab_backup.txt
• crontab -i -r のように -i を付けると、削除前に確認してくれます（対応している実装の場合）

crontabの操作コマンド

書く場所は3種類ある

/etc/crontab と /etc/cron.d/ では、時刻欄とコマンドの間に実行ユーザーを書く必要があります。ユーザーごとのcrontabと同じ書き方をすると、コマンドの先頭がユーザー名として解釈されて動きません。

# /etc/cron.d/backup の例
0 3 * * * app /home/app/backup.sh >> /var/log/app/backup.log 2>&1

Debian・Ubuntuでは、/etc/cron.d/ のファイル名に .（ドット）を含めると読み込まれません。backup.cron ではなく backup のような名前にします。

cronが動かないときの確認手順

上から順に確認すると、ほとんどの原因にたどり着けます。

1. cronのサービスが動いているか

systemctl status cron    # Debian・Ubuntu
systemctl status crond   # RHEL・CentOS・Amazon Linux など

2. cronがジョブを実行したか（ログを見る）

grep CRON /var/log/syslog     # Debian・Ubuntu
sudo cat /var/log/cron        # RHEL系
journalctl -u cron            # systemdのログ（RHEL系は -u crond）

ログに実行の記録がなければ、時刻の指定（タイムゾーン・OR条件）や、書いた場所の書式を確認します。記録があるのに結果が出ていなければ、コマンド側の問題です。

3. コマンド側のエラーを確認する

>> ログファイル 2>&1 で出力を残し、エラーの内容を確認します。多いのは次の3つです。

• PATHが通っていない（落とし穴3）
• % がエスケープされていない（落とし穴2）
• 実行権限がない（スクリプトに chmod +x がされていない）

4. cronと同じ環境で手動実行してみる

env -i SHELL=/bin/sh PATH=/usr/bin:/bin HOME=$HOME /bin/sh -c 'コマンド'

環境変数を最小限にした状態で実行すると、cronで動かない原因を手元で再現できます。

cron式の方言：GitHub Actions・Kubernetes・AWSとの違い

「cron式」はLinuxのcron以外でも使われていますが、サービスごとに細かい違いがあります。ほかの環境の書き方をそのまま持ち込むと、意図しない時刻に動きます。

特にGitHub Actionsは常にUTCなので、日本時間の9時に動かしたいときは 0 0 * * *（UTCの0時＝日本時間の9時）と書きます。

cronとsystemdタイマーの使い分け

最近のLinuxでは、cronの代わりにsystemdタイマーを使う方法もあります。

手軽さならcron、確実性や管理のしやすさを重視するならsystemdタイマー、という使い分けが一般的です。

よくある質問

Q. 秒単位で実行できますか？ A. cronの最小単位は1分です。30秒ごとなら、sleep 30 を使った2行で実現できます（早見表参照）。それより細かい間隔が必要なら、常駐プログラムやsystemdタイマーを検討します。

Q. サーバーが止まっていた時間のジョブはどうなりますか？ A. cronでは実行されず、そのまま飛ばされます。止まっていた間の分も実行したい場合は、anacronやsystemdタイマー（Persistent=true）を使います。

Q. 同じ時刻に大量のジョブを設定しても大丈夫ですか？ A. 毎時0分などに処理が集中すると、サーバーや接続先に負荷が集中します。重要度の低いジョブは、7分・23分のように実行時刻をずらすのがおすすめです。

Q. crontabの設定は反映に再起動が必要ですか？ A. crontab -e で保存すれば、再起動なしで反映されます。

まとめ

• cronは「分 時 日 月 曜日 コマンド」の1行で書く
• 日と曜日を両方指定するとOR条件。「第1月曜」などはコマンド側で判定する
• % は \% にエスケープ、コマンドはフルパスで書く
• サーバーのタイムゾーンを確認する。GitHub Actionsは常にUTC
• 出力は >> ログ 2>&1 で残し、flockで多重起動を防ぐ
• 動かないときは、サービス → ログ → コマンドの順に確認する

あわせて読みたい関連記事

• Linuxでrmしても容量が減らない原因と対処法
• git reset --hardを取り消す方法｜reflogで復元する手順
• APIキーをGitHubにpushしてしまった時の対処手順

株式会社RJCでは、保険・金融・決済などのシステム開発を通じて、こうした運用の知識をチームで共有しています。

▶ RJC丸わかり https://www.r-jc.jp/guide/?mediacode=02-00001-003

▶ エントリーはこちら（1〜2分で完了します） https://www.r-jc.jp/recruitment/?mediacode=02-00001-003

株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。