What is a cron?

The thing that makes your agent wake up on its own and do things for you without you having to be there to ask.

It is 9:00 PM on a Sunday. I'm on the couch. My phone buzzes. The week-ahead brief is in my inbox: every meeting I have on the calendar between Monday and Friday, the open commitments I made last week and haven't closed, the three deals that look like they’re at risk, and the one thing I should lead with on Monday's leadership call. I didn't ask for it. I didn’t have to do anything. The agent fired itself at exactly 9:00 PM because that's the time I told it to.

What it is

A cron is a schedule. More precisely, it's the way computers have agreed to write down schedules since 1975. The word comes from Greek chronos (time), and the format hasn't changed in fifty years because nobody has needed to improve it. A cron schedule is five numbers in a row, separated by spaces, one for each unit of time the schedule cares about.

Read left to right: minute, hour, day-of-month, month, day-of-week. So 0 9 * * 0 reads as minute 0 of hour 9 (9:00 AM), every day-of-the-month, every month, on day-of-week 0 (Sunday). In plain English: 9:00 AM every Sunday. An asterisk means "every one of these." A number means "exactly this one." That's the whole format. Once you can read those five numbers, you can read every cron schedule that exists.

The thing that actually fires the schedule is called a cron daemon on a Unix server, but for a CEO it's usually one of these: GitHub Actions, Vercel Cron, Anthropic's Claude Code Routines, your [harness][2]'s built-in scheduler, or a service like Zapier or n8n. You don't run a server. The platform runs the cron for you. You tell it the five numbers and what to do; it does the rest.

Or you skip all of that and just ask Claude. In Claude Code, you do not need to memorize the five-number format. Say "set up a cron that runs every Sunday at 9 PM and writes me the week-ahead brief" and Claude writes the schedule, wires it to the right scheduler, and confirms when it is live. The five-number format is useful to understand because you will see it everywhere, but you never have to write one by hand if you do not want to.

Why it matters

For the first year I used AI, every workflow started with me remembering to start it. The Monday pipeline pull only happened if I opened my laptop on Monday. The Friday digest only happened if I made it to 5 PM with the energy left to ask for it. I thought I was using AI well. I was actually running manual workflows with extra steps.

The first cron I wired changed the shape of my week. The pipeline pull moved from "Monday morning if I remember" to "Sunday 9 PM, always." I stopped opening Monday with twenty minutes of cleanup and started opening it with a decision. The compounding is real because the marginal cost of adding the second cron is fifteen minutes of setup, not another hour of weekly effort forever.

A cron is the difference between a tool you use and a system that operates. The work happens whether or not you remember it should.

What a good one looks like

A few crons that I run, with the actual schedules in five-number form so you can see what they read like:

• Sunday 9 PM week-ahead brief · 0 21 * * 0 · Pulls calendar, open commitments, at-risk deals; lands in inbox.
• Monday 6 AM pipeline pull · 0 6 * * 1 · Same agent, different lens; weekly view of every active deal.
• Friday 4 PM team digest · 0 16 * * 5 · Reads the week's Slack and [Granola][3] transcripts; writes one note for the team and one for me.
• Every weekday 7 AM inbox triage · 0 7 * * 1-5 · Sorts overnight email into "respond today," "respond this week," and "archive."
• First of the month, 8 AM billing reconciliation · 0 8 1 * * · Walks Stripe and the bank; flags anything that doesn't match.

The pattern: one trigger time, one output, one job. A good cron is small and boring. The leverage comes from running it for a year without touching it.

Common mistakes

Running it too often. Every-minute crons are almost always a mistake for a CEO workflow. The output piles up faster than you can read it. Match the cadence to what you actually need: most of mine are daily or weekly.

Forgetting the timezone. Cron schedules run in whatever timezone the platform defaults to, which is usually UTC. 0 9 * * 1 on a UTC server is 9 AM London, not 9 AM Pacific. Set the timezone explicitly or you will get briefs at 1 AM and wonder what happened.

No monitoring. A cron that fails silently is worse than no cron. Wire a "did it run?" check from day one. The agent should ping you when it skips a fire, not the other way around.

Wiring a one-off on a cron. If the job runs once and you're done, run it once. Crons are for recurring work, not for tasks you'll never repeat.

Setting it for a time nobody reads the output. The 3 AM digest that lands in Slack is a 3 AM digest nobody reads. Schedule the fire for the moment the output is most useful, not the moment the system has spare capacity.

Do this next

The how-to companion is [Run autonomous workflows 24/7 with Claude Code Routines][1]. It walks you through wiring your first cron on Anthropic's servers in about thirty minutes, with the laptop closed. Pick the smallest recurring task you can name. Wire it on a Sunday afternoon. By the second Sunday you will have forgotten you wired it, which is exactly the point.

[1]: /articles/claude-routines [2]: /articles/what-is-a-harness [3]: /articles/what-is-granola