Cron Isn't Sexy But It's Load-Bearing

I checked my token dashboard one afternoon and saw 466,000 tokens consumed. I’d barely touched the system all day.

Dug into the run logs. Multiple cron jobs had fired in overlapping windows. One hit a rate limit. The retry logic kicked in with no backoff and no cap. The retry hit another rate limit. More retries. Each retry burned tokens just to fail again.

It was a feedback loop: rate limit → retry → rate limit → retry → cost spike. I’d built a denial-of-wallet attack against myself.

Cron in the AI era

Traditional cron is fire-and-forget. If two jobs overlap, the worst case is maybe a disk I/O spike or a log file collision. Nobody cares.

When every cron job is an API call to a language model — with per-token pricing, rate limits, and retry behavior — overlapping schedules stop being a minor annoyance and become an operational problem with a dollar amount attached.

Here’s what I was running: an email monitor, a morning briefing, two news digests, a health check, and a couple of utility jobs. Seven jobs total. Not a lot. But several of them were clustered around the same times — :00 and :30 of every hour, because that’s what you write when you’re not thinking about it.

The fixes

Stagger everything. No two jobs fire within the same 2-minute window. The schedule now looks like this:

Time	Job
6:55 AM	Health check
7:00 AM	Morning briefing
7:33 AM	News digest (work/security)
:07, :37	Email monitor (every 30 min, 8am-9pm)
12:35 PM	News digest (tech)

Notice the email monitor runs at :07 and :37 instead of :00 and :30. This keeps it away from the top-of-hour jobs and — less obviously — away from every other system on the internet whose cron fires on the hour mark. API rate limits are shared resources. If you fire at :00, you’re competing with everyone else who wrote 0 * * * * without thinking about it.

Cap retries. Every job now has a maximum of 3 retries with exponential backoff. The original retry logic was uncapped. If the API returned an error, it just tried again immediately. That’s how you turn a rate limit into a feedback loop.

Kill runaway loops. I added monitoring for jobs that exceed their expected token budget. If a run burns more than 3x the normal amount, something is wrong and it should stop, not keep trying.

The boring insight

None of this is novel. Staggered schedules, backoff, retry caps — these are patterns from distributed systems that have been documented for decades. But when you’re building AI automation, it’s easy to focus on the model, the prompts, the triage logic, and treat scheduling as a deployment detail you’ll clean up later.

Later arrived as a $15 afternoon I didn’t notice until I checked the dashboard.

If you’re running multiple AI jobs on cron, spend 20 minutes mapping out when they fire and what happens when one fails. Least exciting work you’ll do on the project, but it’ll save you the most money.