はじめに

サーバー運用では、バックアップの実行、ログのローテーション、定期的なデータ同期など、決まった時間に自動でタスクを実行する仕組みが不可欠です。Linuxではこのタスクスケジューリングを実現する方法として、伝統的な「cron」と、現代的な「systemdタイマー」の2つの選択肢があります。

cronは40年以上の歴史を持つ実績あるツールで、多くのシステム管理者に親しまれています。一方、systemdタイマーはsystemdエコシステムの一部として、より柔軟な制御とログ管理機能を提供します。

本記事では、cronの基本構文からsystemdタイマーの実践的な設定方法まで、タスクスケジューリングの全体像を解説します。両方の仕組みを理解することで、状況に応じた最適な選択ができるようになります。

前提条件と動作確認環境

本記事の内容は以下の環境で動作確認しています。

項目 内容
OS Ubuntu 24.04 LTS / AlmaLinux 9
cron cronie 1.6.1
systemd 255
シェル bash 5.2

WSL2環境でも基本的なcron操作は可能ですが、systemdタイマーを使用するにはsystemdが有効化されている必要があります。

cronとは

cronは、Unix系システムで定期的にコマンドやスクリプトを実行するためのデーモンプロセスです。cronデーモン(crond)がバックグラウンドで常駐し、設定ファイル(crontab)に記述されたスケジュールに従ってタスクを実行します。

graph TB
    A[cronデーモン<br/>crond] --> B{毎分チェック}
    B --> C[crontabファイル]
    C --> D{実行時刻?}
    D -->|一致| E[コマンド実行]
    D -->|不一致| B
    E --> F[結果をメール送信<br/>または出力]
    F --> B

cronの種類

Linuxには複数のcron実装が存在します。

実装 特徴 主な採用ディストリビューション
cronie Red Hat系で標準採用、SELinux対応 RHEL、AlmaLinux、Rocky Linux
Vixie cron 従来のcron、現在はcronieの基盤 歴史的な実装
anacron システム停止中のタスクを起動時に実行 デスクトップLinux
fcron 柔軟なスケジューリング機能 組み込み用途

現代のサーバー環境ではcronieが最も一般的に使用されています。

crontabの基本操作

crontabは「cron table」の略で、cronジョブのスケジュールを定義するファイルです。ユーザーごとに個別のcrontabファイルを持つことができます。

crontabコマンド

crontabの操作には以下のコマンドを使用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 現在のcrontabを表示
crontab -l

# crontabを編集
crontab -e

# crontabを削除
crontab -r

# 他のユーザーのcrontabを編集(root権限が必要)
sudo crontab -u username -e

初めてcrontab -eを実行すると、使用するエディタを選択するプロンプトが表示されます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
$ crontab -e
no crontab for user - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano        <---- easiest
  2. /usr/bin/vim.basic
  3. /usr/bin/vim.tiny
  4. /bin/ed

Choose 1-4 [1]: 

crontabファイルの場所

crontabファイルは以下の場所に保存されます。

ファイル 説明
/var/spool/cron/crontabs/ユーザー名 ユーザー個別のcrontab(Ubuntu/Debian)
/var/spool/cron/ユーザー名 ユーザー個別のcrontab(RHEL系)
/etc/crontab システム全体のcrontab
/etc/cron.d/ システムcrontabのディレクトリ

ユーザーcrontabを直接編集することは推奨されません。必ずcrontab -eコマンドを使用してください。

cron式の構文と書き方

cron式は5つの時間フィールドとコマンドで構成されます。これがcronスケジューリングの核心部分です。

cron式の基本構造

┌───────────── 分 (0-59)
│ ┌───────────── 時 (0-23)
│ │ ┌───────────── 日 (1-31)
│ │ │ ┌───────────── 月 (1-12)
│ │ │ │ ┌───────────── 曜日 (0-7, 0と7は日曜日)
│ │ │ │ │
│ │ │ │ │
* * * * * コマンド

各フィールドの指定方法

記号 意味
* すべての値 * * * * *(毎分)
, 複数の値を列挙 0,30 * * * *(0分と30分)
- 範囲指定 0 9-17 * * *(9時から17時)
/ 間隔指定 */15 * * * *(15分ごと)

月と曜日の名前指定

数値の代わりに英語の省略形も使用できます。

1
2
3
4
5
# 月の指定
jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec

# 曜日の指定
sun, mon, tue, wed, thu, fri, sat

cron式の実践例

日常的によく使われるcron式のパターンを見ていきましょう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 毎日午前3時に実行
0 3 * * * /path/to/backup.sh

# 毎時0分に実行
0 * * * * /path/to/hourly-task.sh

# 5分ごとに実行
*/5 * * * * /path/to/check-status.sh

# 平日の午前9時に実行
0 9 * * 1-5 /path/to/weekday-task.sh

# 毎月1日と15日の午前2時に実行
0 2 1,15 * * /path/to/bimonthly-task.sh

# 毎週日曜日の午前4時30分に実行
30 4 * * 0 /path/to/weekly-maintenance.sh

# 1月から6月の毎日午前6時に実行
0 6 * 1-6 * /path/to/first-half-year.sh

# 平日の営業時間(9時-18時)に30分ごとに実行
*/30 9-18 * * 1-5 /path/to/business-hours-check.sh

特殊な時間指定(ショートカット)

cronieでは、よく使われるスケジュールにショートカットが用意されています。

ショートカット 等価なcron式 説明
@reboot - システム起動時
@yearly 0 0 1 1 * 年1回(1月1日0時)
@annually 0 0 1 1 * @yearlyと同じ
@monthly 0 0 1 * * 月1回(1日0時)
@weekly 0 0 * * 0 週1回(日曜0時)
@daily 0 0 * * * 日1回(0時)
@hourly 0 * * * * 時1回(毎時0分)
1
2
3
4
5
# システム起動時にスクリプトを実行
@reboot /path/to/startup-script.sh

# 毎日バックアップを実行
@daily /path/to/daily-backup.sh

crontabの実践的な設定例

バックアップジョブの設定

データベースのバックアップを毎日深夜に実行する例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# crontab -e で以下を追加
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=admin@example.com

# PostgreSQLデータベースのバックアップ(毎日午前2時)
0 2 * * * pg_dump -U postgres mydb | gzip > /backup/mydb_$(date +\%Y\%m\%d).sql.gz

# 7日以上前のバックアップを削除(毎日午前3時)
0 3 * * * find /backup -name "mydb_*.sql.gz" -mtime +7 -delete

crontabでは%が特殊文字として扱われるため、dateコマンドのフォーマット指定では\%とエスケープする必要があります。

環境変数の設定

cron環境では通常のログインシェルとは異なる最小限の環境変数しか設定されていません。スクリプトが正しく動作するよう、必要な環境変数をcrontabで設定しましょう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 環境変数の設定
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/home/myuser
LANG=ja_JP.UTF-8

# メール送信先
MAILTO=admin@example.com

# MAILTOを空にするとメールを送信しない
# MAILTO=""

# cronジョブの定義
0 * * * * /home/myuser/scripts/hourly-check.sh

ログファイルへの出力

cronジョブの実行結果をログファイルに記録する設定です。

1
2
3
4
5
6
7
8
# 標準出力と標準エラー出力の両方をログファイルに記録
0 * * * * /path/to/script.sh >> /var/log/myscript.log 2>&1

# 日付付きでログを記録
0 * * * * /path/to/script.sh >> /var/log/myscript_$(date +\%Y\%m\%d).log 2>&1

# 出力を完全に破棄(非推奨だが特定の用途で使用)
0 * * * * /path/to/script.sh > /dev/null 2>&1

システムcrontabの設定例

/etc/crontab/etc/cron.d/配下のファイルでは、コマンドの前に実行ユーザーを指定します。

1
2
3
4
5
6
7
8
# /etc/cron.d/my-system-job
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# 分 時 日 月 曜日 ユーザー コマンド
0 4 * * * root /usr/local/bin/system-maintenance.sh
*/10 * * * * www-data /var/www/app/artisan schedule:run

cronのログ確認とトラブルシューティング

cronログの確認

cronの実行ログは、ディストリビューションによって保存場所が異なります。

1
2
3
4
5
6
7
8
9
# Ubuntu/Debian系
sudo grep CRON /var/log/syslog

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

# journalctlを使用(systemd環境)
journalctl -u cron
journalctl -u crond   # RHEL系

cronが動作しない場合のチェックポイント

cronジョブが期待通りに動作しない場合、以下の点を確認してください。

graph TD
    A[cronジョブが動作しない] --> B{cronデーモンは起動中?}
    B -->|いいえ| C[sudo systemctl start cron]
    B -->|はい| D{crontab構文は正しい?}
    D -->|いいえ| E[crontab -e で修正]
    D -->|はい| F{実行権限はある?}
    F -->|いいえ| G[chmod +x script.sh]
    F -->|はい| H{PATHは正しい?}
    H -->|いいえ| I[フルパスで指定]
    H -->|はい| J{スクリプト自体は動作?}
    J -->|いいえ| K[手動実行でデバッグ]
    J -->|はい| L[環境変数を確認]

確認コマンド

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# cronデーモンの状態確認
sudo systemctl status cron    # Ubuntu/Debian
sudo systemctl status crond   # RHEL系

# crontab構文の検証
crontab -l | grep -v "^#" | while read line; do
    echo "Checking: $line"
done

# cronが使用する環境変数の確認
* * * * * env > /tmp/cron-env.txt

よくあるトラブルと解決策

症状 原因 解決策
スクリプトが実行されない PATHが通っていない コマンドをフルパスで記述
文字化けが発生 LANGが設定されていない LANG=ja_JP.UTF-8を追加
出力がメールで届く リダイレクトが未設定 >> /path/to/log 2>&1を追加
権限エラー 実行権限がない chmod +x script.sh
%でエラー エスケープ忘れ \%に変更

systemdタイマーとは

systemdタイマーは、systemdに統合されたタスクスケジューリング機能です。cronの代替として使用でき、systemdの豊富な機能(依存関係管理、リソース制御、ログ統合など)を活用できます。

systemdタイマーの構成要素

systemdタイマーは2つのUnitファイルで構成されます。

graph LR
    A[タイマーUnit<br/>foo.timer] -->|トリガー| B[サービスUnit<br/>foo.service]
    B --> C[実行するコマンド]
    D[systemd] --> A
    D --> B
ファイル 役割
.timer いつ実行するかを定義
.service 何を実行するかを定義

タイマーの種類

systemdタイマーには2種類の時間指定方法があります。

種類 説明 オプション
リアルタイムタイマー カレンダー時刻で指定(cronと同様) OnCalendar=
モノトニックタイマー 相対時間で指定 OnBootSec=, OnUnitActiveSec=など

systemdタイマーの基本設定

サービスUnitの作成

まず、実行したいタスクを定義するサービスUnitを作成します。

1
sudo vim /etc/systemd/system/backup.service
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
[Unit]
Description=Daily Backup Service
After=network.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/backup.sh
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Type=oneshotは、タスク完了後にサービスが終了することを示します。

タイマーUnitの作成

次に、サービスをいつ実行するかを定義するタイマーUnitを作成します。

1
sudo vim /etc/systemd/system/backup.timer
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
[Unit]
Description=Daily Backup Timer

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

タイマーの有効化と開始

作成したタイマーを有効化し、開始します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# systemd設定を再読み込み
sudo systemctl daemon-reload

# タイマーを有効化(自動起動)
sudo systemctl enable backup.timer

# タイマーを開始
sudo systemctl start backup.timer

# 状態を確認
sudo systemctl status backup.timer

OnCalendarの構文

OnCalendarオプションは、cronに相当するカレンダーベースのスケジューリングを提供します。

基本フォーマット

曜日 年-月-日 時:分:秒

例:
Mon 2025-01-08 14:30:00

ワイルドカードと範囲指定

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# 毎日午前2時
OnCalendar=*-*-* 02:00:00

# 毎週月曜日の午前9時
OnCalendar=Mon *-*-* 09:00:00

# 毎月1日の午前0時
OnCalendar=*-*-01 00:00:00

# 平日(月〜金)の午前9時
OnCalendar=Mon..Fri *-*-* 09:00:00

# 毎時30分
OnCalendar=*-*-* *:30:00

# 15分ごと
OnCalendar=*-*-* *:00,15,30,45:00

定義済みの時間表現

systemdには便利なショートカットが用意されています。

表現 等価な指定
minutely *-*-* *:*:00
hourly *-*-* *:00:00
daily *-*-* 00:00:00
weekly Mon *-*-* 00:00:00
monthly *-*-01 00:00:00
yearly *-01-01 00:00:00

OnCalendarの検証

systemd-analyze calendarコマンドで、OnCalendarの解釈と次回実行時刻を確認できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
# 指定した時間表現の解釈を確認
$ systemd-analyze calendar "Mon..Fri *-*-* 09:00:00"
  Original form: Mon..Fri *-*-* 09:00:00
Normalized form: Mon..Fri *-*-* 09:00:00
    Next elapse: Thu 2026-01-08 09:00:00 JST
       (in UTC): Thu 2026-01-08 00:00:00 UTC
       From now: 18h left

# 複数回の実行時刻を確認
$ systemd-analyze calendar --iterations=5 daily
  Original form: daily
Normalized form: *-*-* 00:00:00
    Next elapse: Thu 2026-01-09 00:00:00 JST
       (in UTC): Wed 2026-01-08 15:00:00 UTC
       From now: 9h 30min left
       Iter. #2: Fri 2026-01-10 00:00:00 JST
       Iter. #3: Sat 2026-01-11 00:00:00 JST
       Iter. #4: Sun 2026-01-12 00:00:00 JST
       Iter. #5: Mon 2026-01-13 00:00:00 JST

モノトニックタイマーの設定

モノトニックタイマーは、特定のイベントからの経過時間でスケジューリングします。

よく使用されるオプション

オプション 説明
OnBootSec= システム起動からの経過時間
OnStartupSec= systemd起動からの経過時間
OnActiveSec= タイマーがアクティブになってからの経過時間
OnUnitActiveSec= サービスが最後にアクティブになってからの経過時間
OnUnitInactiveSec= サービスが最後に非アクティブになってからの経過時間

例:起動15分後と、その後1時間ごとに実行

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
[Unit]
Description=Periodic Health Check Timer

[Timer]
OnBootSec=15min
OnUnitActiveSec=1h
Unit=health-check.service

[Install]
WantedBy=timers.target

systemdタイマーの管理

タイマーの一覧表示

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 有効なタイマーの一覧
systemctl list-timers

# すべてのタイマー(無効なものを含む)
systemctl list-timers --all

# 出力例
NEXT                        LEFT          LAST                        PASSED       UNIT                         ACTIVATES
Thu 2026-01-09 00:00:00 JST 9h left       Wed 2026-01-08 00:00:00 JST 14h ago      logrotate.timer              logrotate.service
Thu 2026-01-09 02:00:00 JST 11h left      Wed 2026-01-08 02:00:00 JST 12h ago      backup.timer                 backup.service

タイマーの状態確認

1
2
3
4
5
# タイマーの詳細状態
sudo systemctl status backup.timer

# サービスの実行結果
sudo systemctl status backup.service

手動でサービスを実行

タイマーを待たずにサービスをテスト実行できます。

1
sudo systemctl start backup.service

タイマーのログ確認

journalctlを使ってタイマーとサービスのログを確認します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# タイマーのログ
journalctl -u backup.timer

# サービスのログ
journalctl -u backup.service

# 最近のログのみ表示
journalctl -u backup.service --since "1 hour ago"

# リアルタイムでログを監視
journalctl -u backup.service -f

systemdタイマーの実践例

毎日のデータベースバックアップ

サービスUnit/etc/systemd/system/db-backup.service

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
[Unit]
Description=PostgreSQL Database Backup
Wants=postgresql.service
After=postgresql.service

[Service]
Type=oneshot
User=postgres
Environment=PGPASSWORD=secretpassword
ExecStart=/bin/bash -c '/usr/bin/pg_dump mydb | gzip > /backup/mydb_$(date +%%Y%%m%%d_%%H%%M%%S).sql.gz'
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

タイマーUnit/etc/systemd/system/db-backup.timer

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
[Unit]
Description=Daily Database Backup Timer

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=600

[Install]
WantedBy=timers.target

Persistent=trueを設定すると、システム停止中にスキップされた実行が起動時に行われます。

古いログファイルの削除

サービスUnit/etc/systemd/system/cleanup-logs.service

1
2
3
4
5
6
7
[Unit]
Description=Cleanup Old Log Files

[Service]
Type=oneshot
ExecStart=/usr/bin/find /var/log/myapp -name "*.log" -mtime +30 -delete
ExecStart=/usr/bin/find /backup -name "*.sql.gz" -mtime +7 -delete

タイマーUnit/etc/systemd/system/cleanup-logs.timer

1
2
3
4
5
6
7
8
9
[Unit]
Description=Weekly Log Cleanup Timer

[Timer]
OnCalendar=Sun *-*-* 04:00:00
Persistent=true

[Install]
WantedBy=timers.target

ヘルスチェックの定期実行

サービスUnit/etc/systemd/system/health-check.service

1
2
3
4
5
6
7
[Unit]
Description=Application Health Check

[Service]
Type=oneshot
ExecStart=/usr/local/bin/health-check.sh
ExecStartPost=/bin/bash -c 'if [ $EXIT_STATUS -ne 0 ]; then /usr/local/bin/notify-error.sh; fi'

タイマーUnit/etc/systemd/system/health-check.timer

1
2
3
4
5
6
7
8
9
[Unit]
Description=Health Check Timer (Every 5 Minutes)

[Timer]
OnCalendar=*-*-* *:00/5:00
AccuracySec=1s

[Install]
WantedBy=timers.target

AccuracySec=1sで実行タイミングの精度を高めています。デフォルトは1分の誤差が許容されます。

エラー通知の設定

cronでのエラー通知

cronではMAILTO環境変数でメール通知先を設定します。

1
2
3
4
5
MAILTO=admin@example.com
0 2 * * * /path/to/backup.sh

# 失敗時のみ通知したい場合は出力を制御
0 2 * * * /path/to/backup.sh > /dev/null || echo "Backup failed" | mail -s "Backup Error" admin@example.com

Slackへの通知スクリプト例

1
2
3
4
5
6
7
8
9
#!/bin/bash
# /usr/local/bin/notify-slack.sh

WEBHOOK_URL="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
MESSAGE="$1"

curl -X POST -H 'Content-type: application/json' \
  --data "{\"text\":\"${MESSAGE}\"}" \
  "$WEBHOOK_URL"
1
2
# crontabでの使用
0 2 * * * /path/to/backup.sh || /usr/local/bin/notify-slack.sh "Backup failed on $(hostname)"

systemdでのエラー通知

systemdではOnFailureディレクティブを使用してエラー通知サービスを呼び出せます。

通知サービス/etc/systemd/system/notify-failure@.service

1
2
3
4
5
6
[Unit]
Description=Send Failure Notification for %i

[Service]
Type=oneshot
ExecStart=/usr/local/bin/notify-failure.sh %i

通知スクリプト/usr/local/bin/notify-failure.sh

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
#!/bin/bash

UNIT_NAME="$1"
HOSTNAME=$(hostname)
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

# メール送信
echo "Service ${UNIT_NAME} failed on ${HOSTNAME} at ${TIMESTAMP}" | \
  mail -s "[ALERT] ${UNIT_NAME} failed" admin@example.com

# Slack通知(オプション)
curl -X POST -H 'Content-type: application/json' \
  --data "{\"text\":\"[ALERT] ${UNIT_NAME} failed on ${HOSTNAME} at ${TIMESTAMP}\"}" \
  "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

バックアップサービスにOnFailureを追加

1
2
3
4
5
6
7
[Unit]
Description=PostgreSQL Database Backup
OnFailure=notify-failure@%n.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

cronとsystemdタイマーの比較

どちらを使うべきか迷った場合の判断基準をまとめます。

観点 cron systemdタイマー
設定の簡単さ 1行で記述可能 2ファイル必要
ログ管理 分散(syslog/メール) journaldに統合
依存関係 対応なし 柔軟に設定可能
リソース制御 対応なし cgroup連携
失敗時の処理 メール通知のみ OnFailure指定
デバッグ やや困難 systemctl/journalctlで容易
学習コスト 低い やや高い
可搬性 高い systemd環境限定

使い分けの指針

cronが適している場面

  • シンプルな定期実行タスク
  • 非systemd環境(コンテナなど)
  • 既存のcron設定を維持したい場合
  • 短い1行のコマンド実行

systemdタイマーが適している場面

  • サービス間の依存関係がある場合
  • 詳細なログ管理が必要な場合
  • リソース制限を設定したい場合
  • 失敗時の自動リカバリやエスカレーションが必要な場合
  • systemd環境で運用を統一したい場合

一時的なタイマーの作成(systemd-run)

systemd-runコマンドを使用すると、Unitファイルを作成せずに一時的なタイマーを設定できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 30秒後に1回だけ実行
sudo systemd-run --on-active=30 /bin/touch /tmp/test-file

# 1時間後に実行
sudo systemd-run --on-active="1h" /usr/local/bin/task.sh

# 特定の時刻に実行
sudo systemd-run --on-calendar="2026-01-09 10:00:00" /usr/local/bin/task.sh

# 既存のサービスを1時間後に実行
sudo systemd-run --on-active="1h" --unit=backup.service

テストや一時的なタスクの実行に便利です。

まとめ

本記事では、Linuxにおけるタスクスケジューリングの2つの主要な方法であるcronとsystemdタイマーについて解説しました。

cronは長い歴史を持ち、シンプルな構文で素早く定期実行を設定できます。一方、systemdタイマーはsystemdエコシステムと統合され、依存関係管理やログの一元化など、より高度な機能を提供します。

定期実行タスクを設定する際は、以下のポイントを意識してください。

  1. タスクの複雑さに応じてcronとsystemdタイマーを使い分ける
  2. 環境変数やPATHの設定を忘れずに行う
  3. ログ出力を適切に設定し、実行結果を追跡可能にする
  4. エラー通知を設定して問題を早期に検知する
  5. 本番適用前にテスト環境で動作を確認する

cronの5フィールド形式やsystemdのOnCalendar構文を理解し、定期実行タスクの自動化を実現しましょう。

参考リンク