Cron Jobs Are Your Agent's Heartbeat

The most useful agents are not the ones you interact with. They are the ones that run while you are asleep, while you are in meetings, while you are focused on something else entirely. They check things, summarize things, flag things, and put the results where you will find them. The technology that makes this possible is not new. It is cron.

What Cron Gives You

Cron is a job scheduler built into every Unix-based system, including macOS and Linux. It runs commands on a schedule you define. That is it. No daemon to install, no service to configure, no infrastructure to manage.

For agent workflows, cron provides three things that matter:

• Reliability. Cron has been running scheduled tasks since 1975. It does not crash, it does not need updates, and it does not lose your schedule when you reboot (on most systems).
• No babysitting. Once a cron job is set, it runs whether you are paying attention or not. You do not need to remember to trigger your agent. The schedule handles it.
• Composability. Cron runs shell commands. Anything you can do in a terminal, you can schedule with cron. This means any agent that accepts CLI input can be automated.

Example Cron Patterns for Agents

Here are practical agent schedules that work well in production:

Morning Research Brief (6:00 AM Daily)

0 6 * * * /usr/local/bin/agent-research --topics "ai,startups" --output ~/briefs/$(date +\%Y-\%m-\%d).md

The agent scans your configured sources, pulls relevant articles and updates, and writes a markdown summary to your briefs folder. By the time you sit down with coffee, your daily briefing is waiting.

Hourly Uptime Monitoring

0 * * * * /usr/local/bin/agent-monitor --urls ~/config/watch-urls.txt --alert slack

Every hour, the agent checks your list of URLs, verifies they return 200 status codes, measures response times, and posts to Slack if anything is down or slow. Simple, effective, and it replaces a paid monitoring service.

Weekly Report Generation (Sunday 8 PM)

0 20 * * 0 /usr/local/bin/agent-report --source ~/logs/ --period 7d --output ~/reports/week-$(date +\%U).md

The agent reads your daily logs from the past week, synthesizes them into a weekly summary, highlights completed tasks, flags blockers, and estimates progress against goals. This is the report you never want to write manually.

Git Repository Digest (Every Weekday at 9 AM)

0 9 * * 1-5 /usr/local/bin/agent-git-digest --repos ~/projects/ --since yesterday --output ~/digests/$(date +\%Y-\%m-\%d).md

The agent reviews commits across all your repositories from the previous day, summarizes changes, and flags anything that looks unusual, like large diffs, deleted files, or changes to critical paths.

Setting Up Agent Cron Jobs

The setup is straightforward on both macOS and Linux. Open your crontab for editing:

crontab -e

Add your job using the standard five-field format:

# minute  hour  day-of-month  month  day-of-week  command
# ------  ----  ------------  -----  -----------  -------
  30      8     *             *      1-5          /path/to/your/agent-script.sh

A few things to get right from the start:

• Use absolute paths. Cron does not run in your shell environment. It does not know about your PATH, aliases, or shell config. Use full paths to every binary and file.
• Set environment variables explicitly. If your agent needs API keys or config values, either source them from a file or set them in the crontab itself:

  ANTHROPIC_API_KEY=sk-ant-xxx
  0 6 * * * /usr/local/bin/agent-research --topics "ai"

• Wrap agents in a shell script. Rather than putting complex commands directly in crontab, write a wrapper script that handles setup, runs the agent, and cleans up.

Error Handling and Logging

Cron jobs fail silently by default. If your agent crashes at 3 AM, you will not know unless you set up logging. Always redirect output:

0 6 * * * /path/to/agent.sh >> /var/log/agent-research.log 2>&1

For more robust setups, add these to your wrapper script:

• Timestamps on every run. Prepend each log entry with the date so you can trace when failures occurred.
• Exit code checks. After the agent runs, check $? and log whether it succeeded or failed.
• Lock files. Prevent overlapping runs if a job takes longer than expected:

  LOCKFILE=/tmp/agent-research.lock
  if [ -f "$LOCKFILE" ]; then
    echo "Previous run still active, skipping"
    exit 0
  fi
  touch "$LOCKFILE"
  trap "rm -f $LOCKFILE" EXIT
  # ... run agent ...

• Failure notifications. If a job fails, send a notification. A simple curl to a Slack webhook or an email via mail is enough.

Reactive vs. Proactive Agents

Most people build reactive agents: you ask a question, the agent answers. You give a task, the agent executes. The agent does nothing unless prompted.

Cron turns agents proactive. A proactive agent does not wait for instructions. It operates on a schedule, performing tasks you have predefined, surfacing information you need before you ask for it.

The difference is significant:

• Reactive: "Hey agent, check if the server is down." (You had to notice something was wrong first.)
• Proactive: Agent checks every hour and tells you when something is wrong. (You find out within 60 minutes, even if you were not looking.)

The most effective agent setups combine both. You interact with agents reactively during your working hours and rely on cron-scheduled proactive agents to cover everything else. The cron jobs are the heartbeat: steady, reliable, always running. They are what turn a collection of AI tools into an actual system.

An agent you have to remember to run is just a fancy script. An agent on a schedule is infrastructure.