DevToolBox

cronの実行結果を確認する方法 - ログと標準出力の扱い

最終更新日: 2026-07-22公開日: 2026-07-22執筆: DevToolBox編集部

cronジョブは起動していても、スクリプトの標準出力・標準エラー出力が端末に表示されるわけではありません。結果を確実に確認するには、メールの設定を把握するか、出力をログファイルへ明示的に保存します。

Cron job output is not shown in an interactive terminal. Depending on the implementation, cron may try to mail stdout and stderr to the crontab owner, but explicit log redirection is usually easier to operate and debug.

1. デフォルトの出力はローカルメールへ送られることがある

多くのcron実装は、ジョブが標準出力または標準エラー出力を生成すると、crontabの持ち主へローカルメールで送ろうとします。この仕組みにはsendmailやPostfixなどのMTAが必要です。MTAが未導入・未設定のサーバーやコンテナでは送信に失敗し、結果的に出力が「どこにも見えない」状態になりやすいです。挙動はcron実装と環境に依存します。

2. MAILTOで通知先を指定する

# 出力がある場合の通知先
MAILTO=ops@example.com
* * * * * /path/to/script.sh

# メール通知を抑制
MAILTO=""

MAILTO= をcrontabの先頭に書くと、対応するcron実装で通知メールの送信先を指定できます。MAILTO="" は通知メールを抑制します。外部アドレスへ届けるにはMTA側の配送設定も必要です。

3. MTA未設定環境でメール通知を有効にする

組織のメールリレーがある場合は、Postfixをローカル配送または送信専用のサテライトとして構成できます。インターネットへ直接配送する構成はDNS、送信元認証、迷惑メール対策まで必要になるため、ここでは深入りしません。

# Debian/Ubuntu系の確認例（導入は運用方針に従う）
sudo apt install postfix mailutils

postqueue -p
journalctl -u postfix --since today
printf 'cron mail test
' | mail -s 'cron test' ops@example.com

外部SMTPリレーを使う場合は、relayhost、TLS、認証情報の保管を組織の手順に合わせます。認証情報をcrontabへ直書きしないでください。MTAを常駐させたくないコンテナでは、ログ基盤や外部監視へ送る方が単純なこともあります。

4. stdoutとstderrをログへ追記する

# 標準出力を追記し、標準エラーも同じファイルへ送る
* * * * * /path/to/script.sh >> /var/log/myscript.log 2>&1

# 何も残さない
* * * * * /path/to/script.sh > /dev/null 2>&1

>> は標準出力をファイルへ追記し、2>&1 は標準エラーを標準出力と同じ保存先へ送ります。cronの実行ユーザーがログへ書き込めることを確認してください。長期運用ではlogrotateなどによるローテーションも検討します。

5. cron自体のシステムログを確認する

# RHEL/CentOS系で使われることが多い
sudo tail -f /var/log/cron

# Debian/Ubuntu系で使われることが多い
grep CRON /var/log/syslog

# systemd環境（ユニット名は環境依存）
journalctl -u cron
journalctl -u crond

これらは主にcronがジョブをいつ起動・終了したかなどを調べるログであり、ジョブの標準出力そのものとは別です。保存場所はディストリビューション、syslog設定、cronのユニット名によって異なることがあります。

6. 開始・終了時刻と終了コードを記録する

#!/bin/sh
echo "$(date -Is) job started"

/path/to/task
status=$?

echo "$(date -Is) job finished status=$status"
exit "$status"

date で開始・終了時刻と終了コードを出力しておけば、リダイレクト先のログから実行タイミング、処理時間、成否を検証しやすくなります。

7. logrotateでログ肥大化を防ぐ

追記ログを長期運用するなら、容量上限と保存期間を決めます。次は /etc/logrotate.d/myscript に置く概念例です。実行ユーザー、グループ、アプリがファイルを開き続けるかに合わせて調整してください。

/var/log/myscript.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 appuser adm
}

cronが毎回ログを開き直す単純なリダイレクトでは、通常は次回実行から新ファイルへ書き込みます。常駐プロセスには再オープン処理が必要です。安易な copytruncate はコピー中の欠落リスクがあるため、対象アプリの推奨方法を確認します。

sudo logrotate -d /etc/logrotate.d/myscript
systemctl status logrotate.timer

8. Dead Man's Switchで未実行を検知する

ジョブ自体が起動しなければログも増えません。そこで、完了時だけ外部監視サービスの固有URLへpingし、一定時間届かなければ通知するDead Man's Switchパターンを使えます。healthchecks.ioなど複数のサービスがあります。

#!/bin/sh
PING_URL='https://監視サービスが発行した固有URL'

if /path/to/task; then
  curl --fail --silent --show-error --max-time 10 --retry 3 "$PING_URL"
  exit $?
else
  status=$?
  curl --fail --silent --show-error --max-time 10 "$PING_URL/fail" || true
  exit "$status"
fi

ping URLは知っている人が監視状態を更新できる秘密情報として扱い、公開リポジトリやログへ載せないでください。ネットワーク障害と本処理の失敗を区別するため、タイムアウトとリトライを制限し、通知URLの形式は利用サービスの仕様を確認します。

9. 「出力が見えない」と「cronが動かない」を切り分ける

システムログに起動記録があるのに結果がない場合は、出力先やMTAを確認します。起動記録自体がない場合は、構文、PATH、権限、改行コードなど別の原因を調べます。後者はcronが実行されない時のチェックリストを参照してください。

よくある間違い

English summary

Many cron implementations try to mail non-empty stdout and stderr to the crontab owner, which requires a configured MTA. Use MAILTO= to choose a recipient or MAILTO="" to suppress mail. For predictable diagnostics, append both streams with >> /var/log/myscript.log 2>&1. System cron logs show scheduling activity, not necessarily job output, and their location varies by distribution.

関連ツール / Related tools

Cron Parser

cron式と次回実行予定を確認

関連ガイド / Related guides

cronが実行されない時のチェックリスト

ジョブが起動しない原因を確認

Cron Expression Basics

cron式の書き方と読み方