Skip to content
use-cases / rolling-24h-snapshots / hero
CRON · SNAPSHOTS · ROLLING 24

Keep the last 24 hours as 24 snapshots

A managed cron entry fires @hourly. It POSTs a snapshot named auto-h$(date +%H). The names cycle: auto-h00 through auto-h23. After a day, each new snapshot overwrites the one from yesterday at the same hour — and you always have the last 24 hours of state, retained at hourly granularity.

use-cases / rolling-24h-snapshots / mechanism

One cron line, one naming convention

An @hourly managed entry curls the snapshots URL with alias auto-h$(date +%H). The alias collides intentionally: at hour 13 tomorrow, auto-h13 from today is replaced. Twenty-four named slots, rotated automatically.

cron entry · @hourly
POST · cron/entries
# Hoody Cron — schedule one hourly snapshot.
curl -X POST \
  cron.containers.hoody.com/users/root/entries \
  -H "Content-Type: application/json" \
  -d '{
    "schedule": "@hourly",
    "command": "curl -X POST $SNAP_URL -d '{\"alias\":\"auto-h$(date +%H)\"}'",
    "comment": "rolling 24h snapshot"
  }'
the hour name is the rotation key
snapshot URL · what the cron actually hits
POST · containers/[id]/snapshots
# At 13:00 the cron runs — this is the request it sends:
curl -X POST \
  api.hoody.com/api/v1/containers/$ID/snapshots \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"alias": "auto-h13"}'

# Response:
200 OK · hourly-2026-05-04-13 created in 6s

There is no retention policy and no janitor — the alias auto-h13 is reused every 24 hours, which is what makes the window roll. The Hoody Snapshots API supports an optional alias field on POST /api/v1/containers/[id]/snapshots; reusing it is the entire mechanism.

use-cases / rolling-24h-snapshots / anatomy

Anatomy of one rolling hour

Four steps, all of them inside a single curl. From cron tick to snapshot in seconds.

0113:00:00Cron tick fires@hourly · managed entry
0213:00:04Snapshot POSTedalias auto-h13
0313:00:06Floor materialisedhourly-2026-05-04-13
04+24hSame alias overwrites itno janitor needed

Each tick takes seconds. The alias is the rotation primitive — by reusing the same name 24 hours later, the snapshot at that floor is replaced in place.

use-cases / rolling-24h-snapshots / powers

Three powers of a 24-floor time machine

What you give up by deleting the backup runbook, you get back as something cheaper and more honest.

ECONOMICS

Idle snapshots cost almost nothing

Snapshots are stateless on disk; they don't burn CPU or RAM while sitting there. You're paying for storage of 24 copies of the container's diff, not for a backup service that runs all the time.

GRANULARITY

One hour is the unit of regret

When something goes wrong at 14:14, you restore auto-h13 and you're back at 13:00 — a minute before the issue started. Hourly is fine-grained enough for production rollback and coarse enough not to drown the ledger.

OPERATIONS

No retention rules, no audit

There is no lifecycle policy to write, no S3 bucket to provision, no annual runbook review. The naming convention is the retention rule. The fixed alias set is the audit.

use-cases / rolling-24h-snapshots / economics

What the rolling window costs

Twenty-four snapshots of a typical container, retained at hourly granularity. Numbers come from the Hoody Snapshots API and a representative 1.2 GB diff per hour.

  1. FLOORS RETAINED24

    Each hour is a named slot. After day one, every new snapshot overwrites yesterday's at the same hour — the count never grows.

  2. OF CRONTAB1 line

    One managed entry, schedule @hourly, command curls the snapshots URL with alias auto-h$(date +%H). That is the entire rotation.

  3. JANITORS0

    No prune job, no expires_at policy, no lifecycle config. The alias collision rotates the window in place; nothing accumulates.

Per the Hoody Container Snapshots API: POST /api/v1/containers/[id]/snapshots accepts an optional alias (max 100 chars) and an optional expiry in days. This page assumes containers' default snapshot pricing and a representative ~1.2 GB diff per hourly capture; your sizes will vary with the workload.

use-cases / rolling-24h-snapshots / punchline

Your time machine has 24 floors and the elevator is a curl.

before · backup softwareafter · one cron line
WHAT IT USED TO LOOK LIKERDS snapshots + lifecycle policy + S3 bucket + annual auditfour moving parts · per-GB-day billing · runbook page
WHAT IT LOOKS LIKE NOW@hourly curl POST snapshots -d '["alias":"auto-h$(date +%H)"]'one cron line · one naming convention · 24 floors
use-cases / rolling-24h-snapshots / replaces

What this replaces

The standard reach-for-it tools when you want hourly point-in-time recovery. Each one charges you a service or a retention policy. The cron + alias model charges you neither.

  • AWS RDS snapshotsPer-GB-day billing for a window you can rotate yourself
  • pgBackRest cron jobsA backup tool, a config file, and a daemon for what is one curl
  • custom dump-and-rotate scriptsFragile bash that lists, sorts, and prunes by mtime
  • cron-spawning S3 backup jobsLifecycle policies, bucket versioning, and an IAM role to maintain
  • BTRFS snapshot toolingFilesystem-level snapshots that need a host you control
  • Restic + cronA binary, a repo, a password file, and a retention policy
use-cases / rolling-24h-snapshots / cta

Delete the backup runbook. Schedule the @hourly. The last 24 hours of your container exist as 24 named floors — and the elevator is a single curl.

use-cases / rolling-24h-snapshots / related

Read the others