Cron jobs run an agent session on a schedule. Heartbeats run an agent session at a faster cadence to keep state fresh. The two patterns are how long-lived automation actually gets built — and the design choices around them decide whether the automation is observable or silent.

This piece walks through the patterns Triadive uses for scheduled agent work, the failure modes that show up when the design is loose, and the discipline that keeps scheduled work auditable.

What cron is, in agent terms

In ordinary computing, cron runs a command at a specified time. In agent terms, cron runs an agent session at a specified time. The session has its own intake, its own context, its own tools, its own termination. The schedule is the trigger.

The key shift is that cron is no longer "run a script." It is "spawn a session." The session is the unit of work; the schedule is the trigger; the platform coordinates them.

This shift changes what cron is good for and what it is bad for. Cron is good for work that recurs on a known schedule: daily check-ins, weekly reviews, monthly reconciliations. Cron is bad for work that depends on external state — for that, the pattern is event-driven, not scheduled.

What heartbeats are

A heartbeat is a faster cron, used to keep state fresh. The heartbeat runs every few minutes, inspects the current state, takes a small action, and exits. The pattern is useful for:

  • Detecting new work. The heartbeat checks for new messages, new files, new events. When something is found, the heartbeat spawns a session to handle it.
  • Refreshing cached state. The heartbeat updates caches, reindexes small chunks, and refreshes external connections.
  • Producing visibility. The heartbeat writes a heartbeat log so the operator can see "yes, the system is alive."

A heartbeat is not a worker. It is a probe. The probe inspects state and decides whether a real session should run.

Cron vs heartbeat — the decision

The decision is mostly about cadence:

  • Use cron when the work runs once a day or once an hour or once a week. The work has a stable cadence and the cadence matches how often the work actually needs to happen.
  • Use heartbeat when the work needs to keep state fresh between slower cron runs. The heartbeat itself does not do the work; it triggers sessions that do.
  • Use both when the work has a daily rhythm but also needs to react to events that arrive between daily runs.

A common pattern is a daily cron that produces a digest, with a heartbeat that fires when something interesting arrives between digests.

Designing a cron job

A useful cron job has the following pieces, each one explicit:

1. Schedule. When does the job run? Daily at 4 AM ET? Weekly on Monday? Every 15 minutes? 2. Session goal. What does the spawned session do? A one-sentence description. 3. Scope. What files, what memory, what tools does the session have access to? 4. Termination. When does the session stop? A deadline, a budget, or a written condition. 5. Artifacts. Where does the session write its results? A file path, a state store, a wiki page. 6. Visibility. How does the operator know the job ran? A log line, a status file, a heartbeat.

Each piece has a default. The defaults are:

  • Schedule: daily at a time the workspace is quiet.
  • Session goal: produce a digest, reconcile state, run a check.
  • Scope: read-only access to the workspace's canonical state.
  • Termination: a deadline of a few minutes; a budget of a few thousand tokens.
  • Artifacts: a markdown file in a known location.
  • Visibility: a heartbeat file the operator can cat.

The defaults work for most cron jobs. The point of the design is not to invent clever defaults; the point is to make the defaults explicit.

Designing a heartbeat

A useful heartbeat has a much narrower design:

1. Cadence. How often does the heartbeat fire? Every 5 minutes? Every minute? 2. Probe. What does the heartbeat inspect? New files? New messages? The current state of a known resource? 3. Trigger. When the probe finds something, what happens? Spawn a session. Send a notification. Update a state file. 4. No-op behavior. What does the heartbeat do when the probe finds nothing? Write a "still alive" log line and exit. 5. Cost ceiling. How many tokens does the heartbeat use per fire? Heartbeats should be cheap — typically under 100 tokens.

The defaults are:

  • Cadence: every 5 minutes.
  • Probe: scan a known directory or check a known resource.
  • Trigger: spawn a session, write a state file, or both.
  • No-op: log a "no work" line.
  • Cost: under 100 tokens per fire.

Heartbeats are cheap, but they are not free. A heartbeat that fires every minute and uses 500 tokens a fire is 720k tokens a day. The cost ceiling is the first design choice, not the last.

Failure modes of scheduled work

The most common failure modes:

  • Silent cron. The cron job has been failing for three days and nobody noticed. The fix is at the visibility layer — a heartbeat, a log file, or a dashboard that surfaces "the job ran and produced X."
  • Runaway cron. The cron job's session does not terminate. The fix is at the termination stage — a deadline, a budget, a cap.
  • Overlapping crons. Two cron jobs start at the same time and contend for the same resource. The fix is at the schedule — stagger the crons or use a lock.
  • Heartbeat that does work. The heartbeat has grown from a probe into a worker. The fix is to refactor: the heartbeat probes, a session works.

The first failure mode — silent cron — is the most expensive because it takes the longest to detect. The discipline of visibility is the cheapest insurance.

What scheduled work looks like in practice

A useful setup for a small operator:

  • Daily cron at 4 AM ET. Reads the day's calendar, the inbox, and the workspace state. Produces a "today" digest in daily/YYYY-MM-DD.md.
  • Hourly heartbeat. Scans the inbox for new messages. When a new message arrives, spawns a session to triage it.
  • Weekly cron on Sunday at 6 PM ET. Reads the week's artifacts, produces a "week" summary, appends to long-term memory.
  • Monthly cron on the first. Reconciles the workspace state with the canonical sources. Produces a reconciliation report.

Each cron has a session goal, a scope, a termination, an artifact, and a visibility file. The visibility files live in logs/cron/ so the operator can ls them and see what ran when.

Reading order

The pieces on Triadive that treat scheduled work:

Takeaway

Cron jobs and heartbeats are how long-lived automation gets built. The design is straightforward: a schedule, a session goal, a scope, a termination, an artifact, a visibility file. The discipline is to make every piece explicit and to write the visibility before the work runs.

The most expensive failure mode is silent cron. The cheapest insurance is a heartbeat that logs "still alive." Spend the five minutes.