タイプアンロックステージ本番環境難易度シンプルジョブタスクを自動化対象ソロ起業家対象バックエンド開発者サービスCron サービスファイル Hoody の利点HTTP ネイティブ

use-cases / cleanup-jobs-self-retire / hero

CRON · FILES · SELF-RETIRING

自分自身の引退をスケジュールするクリーンアップジョブ

クリーンアップを始めた日にマネージド cron エントリをプロビジョンします。expires_at は最後の予定実行を少し過ぎた日に設定。スクリプトは夜ごとに作業を切り分けて進め、何も残らなくなったら自分自身を DELETE します。カレンダーリマインダーも、ゾンビ crontab も、年に一度の「クリーンアップのクリーンアップ」レビューも要りません。

Cron ドキュメント

cleanup-stale-uploads.sh

# tail of cleanup-stale-uploads.sh
removed=$(find /uploads -mtime +90 -delete -print | wc -l)
echo "$removed files removed"

# self-aware tail: nothing left → retire
if [ -z "$(ls /uploads)" ]; then
  curl -fsS -X DELETE \
    "$CRON_URL/entries/$ENTRY_ID"
fi

自己認識する末尾。cron エントリは、自身のスクリプトの最後の 1 行です。

cron.containers.hoody.com · cleanup-stale-uploads

https://cron.containers.hoody.com/users/me/entries/cleanup-stale-uploadslive

ENTRY cleanup-stale-uploads@daily · /srv/jobs/cleanup-stale-uploads.sh

EXPIRES 2026-05-05

RUNDATEREMOVEDSTATUS

Day 104-28
{n, plural, =1 {# file} other {# files}'}
ok
Day 204-29
{n, plural, =1 {# file} other {# files}'}
ok
Day 304-30
{n, plural, =1 {# file} other {# files}'}
ok
Day 405-01
{n, plural, =1 {# file} other {# files}'}
ok
Day 505-02
{n, plural, =1 {# file} other {# files}'}
tail
Day 605-03
{n, plural, =1 {# file} other {# files}'}
tail
Day 705-04
0 files
DELETED

LAST EVENTDELETE /entries/{self} · 204

1 日目に古いファイル 247 件をクリア。7 日目はゼロ件 — そして自分のエントリに DELETE を撃ちました。

cleanup-stale-uploads.sh

# tail of cleanup-stale-uploads.sh
removed=$(find /uploads -mtime +90 -delete -print | wc -l)
echo "$removed files removed"

# self-aware tail: nothing left → retire
if [ -z "$(ls /uploads)" ]; then
  curl -fsS -X DELETE \
    "$CRON_URL/entries/$ENTRY_ID"
fi

自己認識する末尾。cron エントリは、自身のスクリプトの最後の 1 行です。

use-cases / cleanup-jobs-self-retire / lifecycle

構造的に有限の寿命を持つクリーンアップ

3 つの離散的なフェーズ。それぞれの遷移は機械的で、人間が思い出す必要はありません。エントリは仕事がいつ終わるか、自分のカレンダー枠がいつ切れるかを知っています。

LIFECYCLE · SCHEDULE → SLICE → SELF-DELETE1 つのエントリ、有限の寿命

1 · SCHEDULE

クリーンアップを始める日にエントリを 1 つ POST

スケジュールは @daily、コマンドはスライサースクリプト、expires_at は最後の予定実行の少し後に設定。締め切りはエントリの中にあります — Notion ドキュメントにも、Slack スレッドにもありません。

2 · SLICE

スクリプトは夜ごとに、優しく削っていく

毎回の実行で古いデータの一部を削除し、データベースを叩き潰さないようにします。1 日目は 247 件、6 日目は 1 件かもしれません。ペースは実際に残っている量で決まります。

3 · SELF-DELETE

仕事が終わったら、エントリは引退する

スクリプトの最後のブロックは、対象が空かを確認します。空なら DELETE /entries/[self] を撃ちます。万が一それが起きなくても、expires_at が数日後に安全網を発動します。

2 つの独立したトリガー — スクリプト自身のチェックと API の expires_at — が同じ結果に収束します: 目的より長く生き残らない crontab 行。

use-cases / cleanup-jobs-self-retire / mechanism

HTTP 呼び出し 2 つ、有限のクリーンアップ 1 つ

Hoody Cron はシステム crontab を JSON-CRUD でラップしたものです。POST がエントリを作成し、DELETE が削除し、expires_at が安全網です。夜ごとに走るスクリプトこそ、いつ終わったかを知っている張本人 — だから DELETE を呼ぶのもそのスクリプトです。

create-entry.sh

DAY 0 · POST

# day 0 — provision the cleanup
curl -X POST \
  https://cron.containers.hoody.com/users/me/entries \
  -H "Content-Type: application/json" \
  -d '["schedule":"@daily","command":"/srv/jobs/cleanup-stale-uploads.sh","expires_at":"2026-05-05T00:00:00Z"]'

# response
HTTP/1.1 201 Created
{ "id":"f3a1", "expires_at":"2026-05-05T00:00:00Z", "enabled":true }

cleanup-stale-uploads.sh

DAY 7 · DELETE

# inside the cron command itself
if [ -z "$(ls /uploads)" ]; then
  curl -X DELETE \
    "$CRON_URL/entries/$ENTRY_ID"
fi

# response
HTTP/1.1 204 No Content
# entry f3a1 was here. f3a1 deleted itself.

$ENTRY_ID は POST が返した UUID — スクリプトはエントリのコマンドラインで渡されたファイルから読むこともできるし、実行時に $HOODY_ENTRY_ID から取ることもできます。いずれにしても、cron エントリが cron エントリを削除します。

use-cases / cleanup-jobs-self-retire / powers

自己引退するクリーンアップが解き放つもの

重要なのは削除そのものではありません。3 か月後に誰もこれの存在を覚えていなくていい、ということです。

PRESSURE-FREE PACING

一気にではなく、スライスごとに

@daily は 24 時間ごとに走ります。スクリプトは古いデータのスライス — ファイル数千、行数千 — を削除して終了します。データベースは静かなまま、負荷曲線はまるで何も起きていないようです。

NO ZOMBIE CRONTAB

行はエンジニアより長生きしない

expires_at は JSON としてエントリに含まれます。発火するとシステム crontab から行が消えます。3 代後のエンジニアが 200 行を遡って cleanup-stale-uploads-v3 が今も何をしているのか首をひねる、ということはありません。

TWO TRIGGERS, ONE OUTCOME

セルフ DELETE と expires_at の安全網

スクリプトは仕事が終わった夜に自身を DELETE します。バグでそのパスが飛ばされても、expires_at が数日後にエントリを引退させます。独立した 2 つの仕組みのうち、どちらかは必ず発火します。

use-cases / cleanup-jobs-self-retire / capacity

これがどうスケールするか

各マネージドエントリは API がシステム crontab に注入する JSON の 1 行です。スケールは Hoody ではなく cron 自身が保持できる量で決まります。

RUN CADENCE1 / day
@daily が定番のクリーンアップリズム。もっと頻繁に走らせたければ、5 フィールド式で * * * * * — 分単位の解像度まで降りられます。
ENTRY LIFETIMEexpires_at
エントリ上の ISO-8601 タイムスタンプ。期限を過ぎると、API は次のスイープでその行を削除します。クリーンアップは自分の締め切りを越えて居座りません。
TEARDOWN HTTPDELETE · 204
実行中のコマンドの内側から DELETE /users/[user]/entries/[id] が動くのは、cron デーモンが自分の crontab をロックしないからです。API が変更を安全にスイープします。

標準の 5 フィールド cron 式とマクロ（@hourly、@daily、@weekly、@monthly、@yearly）。ユーザー単位の分離。各システムユーザーが自分の crontab を持ちます。Hoody Kit の Cron ページは、マネージドエントリと、必要なら従来形の生 crontab アクセスの両方をドキュメント化しています。

use-cases / cleanup-jobs-self-retire / punchline

クリーンアップは、片付ける対象が消えるまで毎晩走る。

BEFORE · カレンダーリマインダー、ゾンビ cron 行AFTER · いつ終わったかを知る cron エントリ

BEFORE// TODO: delete this when /uploads is empty (2026?)未来の自分が一度だけ読み、その後二度と読まないコメント。

NOWDELETE /entries/$ENTRY_ID · expires_at: 2026-05-05スクリプトから発火するティアダウンと、エントリ自体に埋め込まれた締め切り。

Cron API リファレンス

use-cases / cleanup-jobs-self-retire / replaces

これが置き換えるもの

クリーンアップタスクが自然に消え去ることを期待される場面で、これらのパターンを置き換えます。

ゾンビクリーンアップ cron ジョブ2022 年からの行で、誰も削除する勇気が出ない
// TODO: delete this when X is empty永続化してしまったコメント
手作業の janitor スクリプトチームメイトが思い出したときに四半期ごとに走らせる
自分を消さない Kubernetes CronJobttlSecondsAfterFinished はスケジュールではなく Pod に付く
自前のライフサイクルマネージャー他のサービスを監視するためだけの内製サービス
Terraform で管理するライフサイクルポリシーplan、apply、6 か月後にも tfstate に残っている

use-cases / cleanup-jobs-self-retire / cta

クリーンアップをプロビジョンし、引退日を設定し、立ち去りましょう。

Cron ドキュメントを読む

use-cases / cleanup-jobs-self-retire / related

自分自身の引退をスケジュールするクリーンアップジョブ

構造的に有限の寿命を持つクリーンアップ

クリーンアップを始める日にエントリを 1 つ POST

スクリプトは夜ごとに、優しく削っていく

仕事が終わったら、エントリは引退する

HTTP 呼び出し 2 つ、有限のクリーンアップ 1 つ

自己引退するクリーンアップが解き放つもの

一気にではなく、スライスごとに

行はエンジニアより長生きしない

セルフ DELETE と expires_at の安全網

これがどうスケールするか

これが置き換えるもの

他のユースケースを読む

1 つのサーバーで 60 のコンテナ

1 つのリンクで開発者をオンボード

オンデマンドで具現化するAPI エンドポイント

Git のようにコンピュータをブランチ化

スマホで本物の VS Code

他の AI エージェントを生成する AI エージェント

顧客ごとに 1 つのサンドボックスを自動的に

完成したプロトタイプで目覚める

電話から本番環境を緊急修復

誰でも curl できる URL に本番ログを tail

1 つのビルドを 30 の CI ワーカーへ同時にプッシュ

カフェからエージェントの思考を眺める

会議招待ではなく URL で画面を共有

2 つの curl でクラウド間で 200GB を移動

1 行でチームメイトにデータベースの状態を送信

HTTP を読むあらゆるものに LLM トークンをストリーミング

上司が参加せずに観戦できるプログレスバー

構築する必要のなかった Webhook ファンアウト

2 つの curl コマンドだけの CI キャッシュ

スクリプトにドラッグ&ドロップでアップロード

ノートパソコンから 200 人にワークショップを配信

メッセージブローカーなしのコンテナ間 IPC

電車内でエージェントを tail し、終了したら通知を受ける

2 つのターミナルで HTTP 越しのマイク

5 つのエージェント、5 つのパイプ、1 つの判定

今朝のインシデントをチーム全員で再生

今までで最速の「あのファイル送って」

ローカル LLM を実行し、フリート全体に配信

メトリクスバックエンドなしのライブメトリクスダッシュボード

完了したら自分で消える cron ジョブ

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

全顧客に専用 crontab を自動で

午前 3 時にエージェントを起こし、4 時に退役させる

オーケストレーターなしの日次ロールアップ

ブランチごとの crontab を、コードと一緒にデプロイ

シフトとともに失効するオンコールエスカレーション

毎時のスクレイプ、日次のダイジェスト、週次のアーカイブ — 1 つのコンテナで

顧客に自分の cron スケジュールを持ち込んでもらう

スクリプトではなくエージェントをスケジュールする

静かなジョブのためのハートビート

直近 24 時間を 24 個のスナップショットとして保持

今朝の webhook を、明日の同じ時刻にリプレイ

空港のスマホから crontab を編集

200 件の受信箱へファンアウトするスケジュール配信

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

昨日のエージェントを採点するエージェント

SSH セッションなしで TLS 証明書を更新する

本番を壊そうとする毎週のカナリア

生かしておける余裕のある趣味プロジェクトの墓場

プルリクエストごとのプレビュー環境、月中

ベアメタル 1 台で 12 製品ポートフォリオを運営

ステージングサーバー税を撲滅

40 のクライアントサイト、1 つの家賃、1 つのダッシュボード

E2B の請求を、すでにレンタルしているベアメタルに置き換える

アイドル状態のステージングは無料、だからステージングが削除されなくなる

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

S3 の請求項目にならない CI キャッシュ

50 件の営業電話のための 50 のデモ環境