render-cron-jobs

Cron ジョブのレンダリング

このスキルでは、Render の Cron Job サービスについて、スケジュールの実行方法、プラットフォームが保証する内容、ワーカーやワークフローとの違いを説明します。render.yaml やダッシュボードの設定を作成するときは、Blueprint とデプロイスキルも併せてご利用ください。

使用するタイミング

• Cron で起動し、コマンドを実行して、完了したら終了するスケジュール済みの作業
• 定期的なジョブや長時間実行するジョブに cron、バックグラウンドワーカー、ワークフローのどれを使うかの選択
• type: cron、schedule、コマンドに関する Blueprint のフィールド
• 制約：ディスクなし、同時実行は 1 つまで、最長実行時間は 12 時間、プライベートネットワークへのアウトバウンド接続のみ
• UTC によるスケジュール設定の注意点（式はローカル時刻ではありません）

式の早見表、フレームワークの startCommand の例、Heroku Scheduler からの移行対応表は references/ にあります。

cron ジョブのアウトバウンドのプライベートネットワーク接続を設定またはトラブルシューティングする前に、references/private-networking.md をお読みください。 cron ジョブ、ワーカー、Workflow のいずれを使うか選ぶ際は、references/service-types.md をお読みください。

設定

• スケジュール：チームのローカルタイムゾーンではなく、UTC で評価される cron 式です。ダッシュボードと Blueprint に表示される時刻はすべて UTC です。
• コマンド：有効な Linux シェルコマンド、または bash スクリプトのパスを指定できます。作業が終わったらプロセスを終了させる必要があります。実行時間が長くなると、課金対象のコンピューティングリソースをより多く消費します。最新の詳細は Render の料金でご確認ください。
• ソース：
  • Git リポジトリ — Render はプッシュ時にビルドします（リポジトリに基づく他のサービスと同じデプロイモデルです）。ビルドされたアーティファクトは、スケジュールされた各実行時に動作します。
  • ビルド済み Docker イメージ — イメージは実行ごとにプルされ、実行間で保持されません（長時間稼働するサービスのように、同じサービス内の実行間でイメージレイヤーセットのウォームキャッシュが使われることはありません）。

制約

• 永続ディスクなし — cron ジョブサービスでは、Render の永続ディスクをプロビジョニングまたは接続できません。そのため、代わりにオブジェクトストレージやデータベースを利用してください。
• 単一実行の保証 — cron サービスごとに、同時に実行中となるのは最大 1 つです。新しいスケジュール時刻になっても、重複する 2 つ目のインスタンスは起動しません。
• 最長実行時間：実行 1 回につき 12 時間です。
• 料金：cron ジョブの実行には追加料金が発生します。最新の詳細は Render の料金でご確認ください。
• プライベートネットワーク：cron ジョブは、プライベートネットワーク上の他のサービス宛てにトラフィックを送信できます。一方、プライベートネットワークからの受信接続はできません（他のサービスからのトラフィックを受け付ける内部ホスト名はありません）。

実行時の動作

• 実行が進行中のときに手動で「Trigger Run」を実行すると、Render は進行中の実行をキャンセルしてから、新しい実行を開始します。
• 新しい Git ビルド／デプロイは、すでに進行中の実行には影響しません。実行中のプロセスは終了するまで、開始時に使用していたリビジョンを使い続けます。
• Docker ベースの cron：イメージは実行ごとに新たにプルされます。継続的に実行されるコンテナのように、実行間でレイヤーやイメージが再利用されるとは考えないでください。
• すべて UTC：cron 式やドキュメントでの「真夜中」は UTC を意味します。よくある間違いは、ローカル時刻のスケジュールを UTC に変換せず、そのまま式にコピーすることです。

Cron、ワーカー、ワークフローの比較

必要な処理	使用するもの	理由
12 時間未満の定期タスク	Cron Job	スケジュールに従って実行し、完了したら終了します
継続的なジョブ処理	Background Worker	常に稼働し、キューをポーリングします
12 時間を超える定期タスク	Background Worker	cron の実行時間に 12 時間の上限がありません
スケジュールされた並列コンピューティング	Cron Job + Workflow	cron がスケジュールに従ってワークフローの実行を開始し、ワークフローが処理を複数に分割するか、並列ステップをオーケストレーションします

Blueprint の設定

Cron サービスでは、type: cron に schedule と、通常のビルド／起動および環境変数の設定を組み合わせます。

services:
  - type: cron
    name: nightly-cleanup
    schedule: "0 * * * *" # hourly at minute 0 — must be quoted in YAML
    buildCommand: pip install -r requirements.txt
    startCommand: python cleanup.py
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: my-db
          property: connectionString

• schedule：標準の 5 フィールド形式の cron（minute hour day-of-month month day-of-week）で、タイムゾーンは UTC です。
• buildCommand ／ startCommand：Docker を使わない他のサービスと同じ役割です。Docker イメージの場合は、イメージベースの Cron 用に設定されたイメージと起動コマンドを使用します。
• envVars：Web サービスやワーカーと同じパターン（シークレット、リンクされたデータベースなど）を使用します。

YAML に関する注意：* などの文字が YAML のエイリアスやフロー構文として解析されないよう、schedule の値は 引用符で囲む必要があります。

よくあるパターン

• データベースのクリーンアップ — 古くなった行を定期的にアーカイブまたは削除します
• レポートの生成 — CSV／PDF を作成し、オブジェクトストレージにアップロードするか、メールで送信します
• 外部 API の同期 — 一定間隔でデータをまとめて取得または送信します
• キャッシュのウォームアップ — ピーク時のトラフィックに備えて、エンドポイントにアクセスするか、キャッシュを再構築します
• メールの定期送信 — cron とメール／API を使用して、ダイジェストやリマインダーを送信します

参考資料

トピック	ファイル
プライベートネットワークの範囲、内部アドレス、トラブルシューティング	references/private-networking.md
サービス種別の選択と実行モデル	references/service-types.md
式の例、フレームワークのコマンド、エラー、環境変数	references/cron-patterns.md
Heroku Scheduler から Render へのマッピング、Blueprint の例	references/migration-from-scheduler.md

関連スキル

• render-deploy — 初回デプロイ、サービスの作成、ダッシュボードの操作
• render-blueprints — render.yaml の全スキーマ、プレビュー、よくある間違い
• render-background-workers — 長時間実行プロセス、キュー、12 時間の上限なし
• render-workflows — オーケストレーションされたジョブや並列ジョブ。多くの場合、cron からスケジュールに基づいてトリガーされます

現行ドキュメントの取得

このスキルで現行の Render ドキュメントを参照するよう指示された場合は、必ず次の手順に従ってください。

1. curl など、利用可能な URL 取得ツールまたは HTTP クライアントを使って、リンク先の Markdown ドキュメントを直接取得します。ウェブ検索の要約でドキュメントを代用しないでください。
2. 取得に成功し、想定したドキュメントが返されたことを確認してから、その内容を読みます。ファイルを保存したり、そのパスを表示したりするだけでは不十分です。
3. リクエストに失敗した場合、またはツールで Markdown のレスポンスを読めない場合は、リンク先の HTML 版を開いて読みます。
4. どちらのバージョンも取得できない場合は、現行の参照資料を利用できないことを明示し、スキル内の該当トピックに固有の代替手順に従います。安定した制約に限って同梱のガイダンスを使用し、変更される可能性のあるプラットフォームの詳細を推測しないでください。

複数の参照資料が必要なタスクでは、それぞれにこの手順を適用し、確認できたドキュメントと取得できなかったドキュメントを区別してください。