コンテンツにスキップ
タイプ標準ステージクイックウィン難易度シンプルジョブタスクを自動化対象開発チーム対象DevOps & インフラサービスCronHoody の利点HTTP ネイティブ
タイプ標準ステージクイックウィン難易度シンプルジョブタスクを自動化対象開発チーム対象DevOps & インフラサービスCronHoody の利点HTTP ネイティブ
タイプ標準ステージクイックウィン難易度シンプルジョブタスクを自動化対象開発チーム対象DevOps & インフラサービスCronHoody の利点HTTP ネイティブ
タイプ標準ステージクイックウィン難易度シンプルジョブタスクを自動化対象開発チーム対象DevOps & インフラサービスCronHoody の利点HTTP ネイティブ
ユースケースに戻る
use-cases / mute-flaky-job / hero
CRON · MANAGED ENTRIES · PATCH

不安定なジョブを失わずにミュートする

1 時間ごとのメトリクスエクスポートが 3 日間失敗し続けています。今夜はあなたがオンコールです。マネージド cron エントリに enabled:false を PATCH しましょう。スケジュール、コマンド、コメントはすべて残ります。ジョブは定義された状態にあります。存在しつつミュートされ、誰かの修正を待っています。

cron ドキュメントを読む

トグルは PATCH 1 回 · エントリはリストから消えません

use-cases / mute-flaky-job / mechanism

ミュートはたった 1 回の PATCH

Hoody Cron のマネージドエントリは JSON リソースです。各行は id、schedule、command、comment、enabled フラグを持ちます。enabled を false に切り替えるのは PATCH 1 回。エントリは crontab に残るので、次の担当者が読んで判断できます。

terminal · オンコールのノート PC
PATCH · mute
# mute the flaky entry — entry stays in the crontab
curl -X PATCH \
  https://cron.containers.hoody.com/users/me/entries/e7d3 \
  -H "Content-Type: application/json" \
  -d '["enabled": false, "comment": "flaking on monday with prod-db — see #pager"]'

# response
HTTP/1.1 200 OK
{ "id":"e7d3", "enabled":false, "schedule":"0 * * * *",
  "command":"/srv/cron/metrics-export.sh", ... }
terminal · 翌朝
GET · verify
# the entry is still on the list — just not running
curl GET https://cron.containers.hoody.com/users/me/entries

HTTP/1.1 200 OK
[
  { "id":"a1f2", "enabled":true,  ... },
  { "id":"e7d3", "enabled":false, "comment":"flaking — see #pager" },
  { "id":"9b21", "enabled":true,  ... }
]
# present and muted — the on-call hand-off has somewhere to point

PATCH はエントリを削除も、書き換えも、移動もしません。1 つの真偽値を反転させるだけです。引き継ぎは 1 行で済みます。「metrics-export entry e7d3 はミュート中、hoody-cron を見て確認してほしい」。

use-cases / mute-flaky-job / states

3 つの状態、1 つのエントリ

Hoody crontab 上のエントリは、常に 3 つのうちのいずれかひとつの状態にあります。それぞれの状態が、翌朝の「誰が何を知っているか」に異なる結果をもたらします。

ENTRY · e7d3 · /srv/cron/metrics-export.shPATCH は状態を切り替えます — 破壊的ではありません
ENABLED

スケジュール通り実行、失敗時はページング

エントリは crontab にあり、カーネルの cron デーモンが 1 時間ごとに拾います。失敗するとオンコールが起こされます。健全なジョブのデフォルトです。

MUTED

存在しつつ、停止中、注釈付き

enabled:false。エントリは crontab に残るので、チームはスケジュール、コマンド、コメントを読めます。cron デーモンはスキップします。明日の午前 2 時のページングはなく、誰もエントリの存在を忘れません。

DELETED

消失 — そしてコンテキストも消える

DELETE すると、スケジュールも、コマンドも、コメントも、理由も、すべてが crontab から消えます。次のオンコールには grep する手がかりがありません。記憶を残すのはミュートという選択肢です。

ミュートは、ほとんどのスケジューラに名前がない中間状態です。Hoody Cron にはあります。enabled がマネージドエントリの一級フィールドだからです。

use-cases / mute-flaky-job / powers

なぜ「定義されたミュート状態」が重要なのか

今夜ジョブを修正できないとき、問題は「明日までにその不在がどんな形を取るか」です。ミュートはその形を読み取れるようにします。

HAND-OFF

オンコールへのメッセージは 1 行で済む

Slack スレッドや削除済み行の PR を貼る代わりに、メッセージはエントリ id だけ。明日のオンコールが cron URL を開き、コメントを読み、どこから始めるかが分かります。

AUDIT

すべてのミュートは記憶ではなく行になる

GET /entries はコメントとともに enabled:false を返します。フィルタリングで監査パネルを構築できます。誰がミュートしたか、なぜか、どれくらい前かは JSON の中にあり、誰かの DM の中にはありません。

REVERSIBLE

ミュート解除は逆向きの PATCH

根本の問題が解消したら、もう 1 回 enabled:true で PATCH すればエントリはスケジュールに戻ります。cron 式を書き直す必要も、タイポのリスクも、コミットとデプロイのサイクルもありません。

use-cases / mute-flaky-job / capacity

cron API が提供するもの

数値は Hoody Cron のマネージドエントリ表面から得たもので、捏造したベンチマークではありません。

  1. ONE METHODPATCH

    PATCH /users/[user]/entries/[id] は部分ボディを受け付けます。["enabled":false] だけを送ってください — schedule、command、comment はそのままです。

  2. FIELDS PRESERVED5+1

    5 フィールドのスケジュール、command、comment、expires_at、id はミュートを越えて保持されます。カーネルの crontab にもエントリは反映されたまま — cron サービスがコメントアウトしているだけです。

  3. REWRITES0

    ファイル編集も、PR も、デプロイもありません。ミュートの往復はどんなターミナルからでも HTTP 呼び出し 1 回 — スマホのターミナルでも構いません。

Hoody Cron Managed Entries API に基づく: 各エントリは schedule、command、comment、任意の expires_at と並んで enabled の真偽値を持ちます。PATCH は部分ボディを受け付けます。

use-cases / mute-flaky-job / punchline

Disabled は Deleted ではない — エントリは誰かの修正を待っている。

今夜 · オンコール · 23:14明日 · チーム · 09:00
古いワークフローはこうだったvim crontab → 行をコメントアウト → コミット → PR → マージ → デプロイ6 ステップ · コメントの文脈を失う · 疲れた夜にタイポを招く
今はこう見えるcurl -X PATCH .../entries/e7d3 -d '["enabled":false]'PATCH 1 回 · エントリはリストに残る · メモも一緒に残る
PATCH 仕様を見る
use-cases / mute-flaky-job / replaces

これが置き換えるもの

チームが不安定な cron 行を「一時的に」棚上げするときの典型的なやり方。どれも破壊的か、情報を失うか、本番から PR 2 回分離れています。

  • crontab の行を手作業でコメントアウト構造化された enabled フラグを失う · 忘れがち
  • エントリを削除して「覚えておく」スケジュール、コマンド、理由がまとめて消える
  • コード内の手書き // FIXME コメント実行されるスケジュールではなく、リポジトリの中に住む
  • オンコールの記憶代わりの Slack スレッド1 週間は検索可能 · その後は誰の仕事でもない
  • ミュートはしたが削除はしていないジョブの GitHub Issueまだ crontab にあるものの Issue — 二重状態
  • Terraform で管理する cron 設定plan、apply、deploy — たった 1 つの真偽値フィールドのために
use-cases / mute-flaky-job / cta

午前 2 時に不安定なジョブを削除するのはやめましょう。ミュートし、メモを残し、明日のオンコールに JSON を読ませましょう。

cron ドキュメントを読む
use-cases / mute-flaky-job / related

他のユースケースを読む

夜間マイグレーションの直前にコンテナをスナップショット

02:55 UTC に発火する hoody-cron エントリが snapshots URL を curl し、アーティファクトに pre-migration-2026-05-04 という名前を付けます。5 分後にマイグレーションが実行されます。成功すればスナップショットは何もせずコストもかかりません。失敗した場合は、たった 1 つの PATCH で 30 秒以内に復元できます。

Cron·スナップショット

フリート規模で顧客ごとのサンドボックス

800 の顧客が 3 台のベアメタルサーバーに分散 — 定額の月額請求、顧客ごとのメーターなし。各テナントは独自のカーネル名前空間、ファイルシステム、URL を持つ本物のコンテナを取得します。ほとんどはほとんどの時間アイドル状態で、すでに支払っているサーバーに上乗せでかかる費用はゼロです。

コンテナ·スナップショット·Exec