crontab からの移行

crontab は実行して忘れます。リトライもなく、タイムアウトもなく、スクリプトが静かに失敗しても アラートはなく、何が実行されたか・何を返したかの記録もありません。このガイドでは典型的な crontab を SteadyCron マニフェストにマッピングし、得られるメリットを説明します。

典型的な crontab

# /etc/cron.d/myapp
MAILTO=""

# Weekly digest — every Monday at 09:00 Berlin time
0 9 * * 1 www-data /var/www/myapp/bin/send-digest.sh

# Nightly DB backup — every day at 02:00
0 2 * * * www-data /var/www/myapp/bin/backup.sh >> /var/log/backup.log 2>&1

# 15-minute health sweep
*/15 * * * * www-data /var/www/myapp/bin/health-check.sh

対応する SteadyCron マニフェスト

namespace: myapp

channels:
  - id: team-email
    kind: email
    email: oncall@myapp.com

jobs:
  # HTTP ジョブ：SteadyCron がエンドポイントを直接呼び出す。
  # 失敗時はリトライ；失敗が続く場合はチャンネル経由でアラート。
  - id: weekly-digest
    name: Weekly digest email
    kind: http
    method: POST
    url: https://api.myapp.com/jobs/send-digest
    schedule: "0 9 * * 1"
    timezone: Europe/Berlin
    timeout: 120
    retries: 3
    channel: team-email

  # ハートビート：バックアップスクリプトが完了後に SteadyCron に ping を送る。
  # ping が届かなかったり遅延した場合に SteadyCron がアラートを発する。
  - id: nightly-backup
    name: Nightly DB backup
    kind: heartbeat
    schedule: "0 2 * * *"
    grace: 1800
    channel: team-email

  # ハートビート：ヘルスチェックスクリプトが各実行後に ping を送る。
  - id: health-sweep
    name: 15-minute health sweep
    kind: heartbeat
    schedule: "*/15 * * * *"
    grace: 120
    channel: team-email

マッピングルール

crontab の概念	SteadyCron の対応
スケジュール式	schedule — 同じ 5 フィールドのクロン構文
MAILTO=""（メール抑制）	channel フィールドを省略（アラートなし）
TZ= 環境変数によるタイムゾーン	ジョブごとの timezone フィールド
エンドポイントを呼び出すスクリプト	kind: http ジョブ
自分で管理するスクリプト（サーバー上で実行）	kind: heartbeat — スクリプトが成功時に SteadyCron に ping を送る
ログファイルへのリダイレクト	SteadyCron が完全なリクエスト/レスポンスログを保存；リダイレクト不要
2>&1（stderr のキャプチャ）	SteadyCron が HTTP レスポンスからステータスとボディの両方をキャプチャ

HTTP ジョブとハートビート：どちらを使うべきか？

kind: http を使用するのは、クロンのロジックが自身が所有する HTTP エンドポイントの背後に ある場合です。SteadyCron がスケジュールに従って呼び出し、リトライを処理し、レスポンスを記録し、 失敗時にアラートを発します。crontab エントリとシェルスクリプトが不要になります — エンドポイント がジョブそのものです。

kind: heartbeat を使用するのは以下の場合です：

• スクリプトがサーバー上で直接実行される（シェル、Python、PHP など）
• HTTP エンドポイントを公開できない、または公開したくない
• スクリプトがすでに存在しており、監視だけを追加したい

ハートビートの場合、スクリプトの末尾に SteadyCron の ping URL への curl 呼び出しを 1 つ 追加します：

#!/bin/bash
set -euo pipefail

# ... バックアップのロジック ...

# SteadyCron に成功を通知
curl -fsS https://ping.steadycron.com/{your-token}

Python、Ruby、PHP、Node.js などのスニペットは あらゆる言語からの Ping を参照してください。

得られるメリット

	crontab	SteadyCron
失敗時のアラート	なし	あり — メール、Slack、Discord、Telegram、webhook
実行失敗時のアラート	なし	あり — 設定可能なグレース期間付き
リトライ	なし	あり — ジョブごとに設定可能
タイムアウトの強制	なし	あり — ジョブごと
実行ログ	なし（ログローテーション）	あり — 完全なリクエスト/レスポンス履歴
バージョン管理	容易でない	あり — マニフェストがリポジトリに存在
ジョブごとのタイムゾーン	TZ= の回避策経由	ネイティブな timezone フィールド
変更の PR レビュー	なし	あり — CI での steadycron plan

自動インポート

マニフェストを手動で書く代わりに、steadycron import crontab を使って既存の crontab ファイルから自動生成できます：

# ファイルから
steadycron import crontab /etc/cron.d/myjobs -o steadycron.yaml

# crontab -l から（現在のユーザーのジョブ）
crontab -l | steadycron import crontab -o steadycron.yaml

# 書き込まずにプレビュー
steadycron import crontab mycron.txt --dry-run

インポーターは各エントリを自動的にジョブの種類にマッピングします：

コマンドの種類	変換先
curl/wget/https://… URL	http ジョブ — URL、メソッド、ヘッダーを抽出
その他すべて	heartbeat モニター

--as http または --as heartbeat ですべてのエントリを特定の種類に強制できます。

対応する crontab の慣例： MAILTO= や PATH= などの環境変数割り当て行は無視されます。エントリの直前にある # コメント はジョブの name になります。@daily、@weekly、@monthly などのマクロは 5 フィールドの cron 式に展開されます。システム crontab 形式（6 番目のフィールドがユーザー名）は自動検出されるか、--system で強制できます。

インポート後にマニフェストを確認して同期します：

steadycron validate steadycron.yaml
steadycron sync steadycron.yaml --namespace prod

次のステップ

1. マニフェストを適用する：steadycron sync manifests/myapp.yaml
2. ハートビートジョブの場合：スクリプトに ping URL を追加する
3. 変更をレビューする CI をセットアップする：CI/CD セットアップ
4. 既存のダッシュボードジョブの場合：IaC への移行