Short definition
Cron — a scheduler in operating systems that automatically runs tasks at preset times, such as a script every night or on the first day of each month.
Also known as: cron job, scheduled task, crontab.
Cron is the oldest and most widely used way to run tasks automatically at fixed times. The name comes from the Greek chronos (time): a background process checks every minute whether a task is scheduled and runs it. What started as Unix system administration is today the standard metaphor for all scheduled automation — from nightly backups to an AI agent that analyzes your Search Console data every month.
How does cron work?
A cron job consists of two parts: a command and a time schedule. The schedule is an expression of five fields — minute, hour, day of the month, month, and weekday — that together determine when the command runs. 0 3 * * * runs a task every night at 03:00; 0 9 1 * * on the first of every month at 09:00.
Two properties make cron so practical:
- It runs unattended. The task starts even when nobody is watching, on a server or in an agent platform that is always on.
- A predictable rhythm. The same schedule, every time. That makes cron ideal for periodic work you can rely on — and whose data you can compare, because the measurement moments always fall at the same time.
Cron and AI agents
More and more often, what runs on a cron schedule is not a shell script but an AI agent. Take an SEO loop: every thirty days the agent pulls fresh Search Console data, analyzes where your pages are winning or losing, and prepares one small improvement. In Automating SEO with AI you can read how to build such a loop and why you only let it run automatically after a period of supervision.
The rule from workflow automation applies here too: only automate what you have first run reliably by hand. An agent on cron without solid rules is just an elaborate way to make mistakes faster.
Good habits
A scheduled task is only reliable with three provisions around it:
- Logging. Every run records what happened, so you can reconstruct afterwards why a result turned out differently.
- Failure alerts. A cron job that fails silently is worse than no automation: you think something is running that has in fact been down for weeks.
- Idempotency. If a task accidentally runs twice, that must not cause double effects. Good tasks check their own state first.