Dead man's switch for AI agents: how to know a scheduled run failed silently

A dead man’s switch is a monitor that expects to hear from something on a schedule, and alerts the moment it doesn’t. Trains have had them for over a century: let go of the handle, the train brakes. Applied to software, the idea is the same — a scheduled job should report in, and silence is treated as a failure, not a non-event.

Cron jobs have needed this for decades. Scheduled AI agents need it more, because they fail in a way plain cron mostly doesn’t: they finish without error, and did nothing.

Why “it ran” tells you less for an agent

A traditional cron job that fails usually says so — a non-zero exit code, a stack trace, a process that dies. An agent loop is built to absorb exactly that kind of failure and keep going: a tool call errors, the model apologizes in its next turn, the run completes, exit code 0. Nothing was written, and nothing looks wrong.

Agents also inherit failure modes cron never had:

• Rate limits and spend caps. A 429 storm or an exhausted monthly budget quietly ends tonight’s run — and tomorrow’s.
• Hung calls. Plenty of LLM SDKs ship without a request timeout. One wedged connection and the run never finishes; it isn’t failed, it’s just gone quiet.
• Model drift. A provider deprecates a model ID or reshapes a response on their schedule, not yours. The job breaks without a deploy on your side.

None of these produce a log line anyone is watching at 2 AM. That’s the actual problem a dead man’s switch solves: it doesn’t need to know why the run went quiet, only that it did.

The pattern

Move the “did it work?” question off the process that might itself be stuck. The agent pings an external URL when it finishes; if the ping doesn’t arrive within an expected window, the switch fires.

The detail that matters for agents specifically: ping success only after validating the output, not on process exit.

curl -fsS https://ping.steadycron.com/<your-ping-token>/start
python run_agent.py --task nightly-digest && test -s out/digest.md \
  && curl -fsS https://ping.steadycron.com/<your-ping-token> \
  || curl -fsS https://ping.steadycron.com/<your-ping-token>/fail

test -s out/digest.md is the whole trick — it checks that a non-empty artifact actually exists before reporting success. An agent that “completed” with an empty output file now reports /fail, which is what actually happened.

The /start ping matters too: without it, a hung call just looks like a late run. With it, a run that started but never finished shows up as stuck, not merely delayed — useful when the failure is a wedged API call rather than a trigger that never fired at all.

It doesn’t replace watching the scheduler layer

A missing ping tells you the agent didn’t produce a valid result — it doesn’t tell you whether the cause was the agent or whatever triggered it. If nothing started the process at all, the fix is upstream: check GitHub Actions schedules, Kubernetes CronJobs, or Vercel Cron for the trigger-layer causes specific to that platform. The dead man’s switch is what tells you something is wrong on a night you weren’t looking; diagnosing which layer broke still means checking the trigger first, then the run.

Where SteadyCron fits

This is heartbeat monitoring, applied to agents instead of cron jobs — no different mechanism, just a different thing pinging in. Set a grace period that matches how long a real run takes, ping /start and /success (only after validating output) or /fail, and SteadyCron alerts you on Slack, email, Telegram, Discord, or webhook the moment a valid result stops arriving, for any of the reasons above.

See Cron jobs for AI agents for the full pattern, including moving the trigger itself onto SteadyCron as a hosted HTTP job. Debugging a run that’s already gone quiet? Start with Scheduled AI agent not running.

Start free — no credit card required.