A cron job is a task that a computer runs automatically on a schedule, such as every night at 2:00 or every fifteen minutes. The name comes from cron, the scheduler built into Unix systems. Today the same idea runs on servers, hosting platforms, CI services, and desktop operating systems.
A surprising amount of what we run happens when nobody is at a keyboard. A program checks public court records and reports what changed. Another reads a law firm's incoming email. Another writes and publishes an article each morning. None of them wait for a person to press a button. Each one is started by a schedule.
Scheduled tasks are the least glamorous part of automation and one of the most useful. If you understand how they work, you can ask better questions about any system that is supposed to "run automatically".
What is a cron job?
A cron job is a command or program that runs automatically at times you define in advance. Cron is the scheduling service on Unix and Linux systems. People now use "cron job" loosely for any scheduled task, whichever tool does the scheduling.
A cron job has two parts: a schedule and a command. The schedule says when. The command says what. The scheduler's only job is to start the command at the right moment. Everything else, including noticing whether the command worked, is up to the program and the people who own it.
How do you read a cron expression?
A cron expression is five fields separated by spaces: minute, hour, day of month, month, and day of week. An asterisk means "every". Read left to right, the expression tells the scheduler exactly which minutes of which days the job should start.
┌ minute (0-59)
│ ┌ hour (0-23)
│ │ ┌ day of month (1-31)
│ │ │ ┌ month (1-12)
│ │ │ │ ┌ day of week (0-6, Sunday is 0)
│ │ │ │ │
30 7 * * * every day at 7:30
*/15 * * * * every 15 minutes
0 9 * * 1-5 9:00 on weekdays
0 2 1 * * 2:00 on the first of each monthTwo things catch people out. First, the time zone. Many hosted schedulers run on UTC, so "7:30" may not be your 7:30. Second, hosted schedulers often treat the time as a target, not a promise. A job set for 7:30 may start a few minutes late when the platform is busy. Do not build anything that depends on the exact second.
What are the ways to schedule a task?
There are three common ways to schedule a task without running your own server: a CI service that starts a job on a timer, a hosting platform's built-in scheduler, and the task scheduler in a computer's operating system. Each suits a different kind of job.
We use all three.
| Option | How it works | Good for | Watch out for |
|---|---|---|---|
| CI runner | A code hosting service runs your script on a schedule | Small standalone scripts that fetch, compare, and report | Start times can drift, and run time is limited |
| Hosting platform scheduler | The platform calls a function in your app on a schedule | Jobs that belong to a web app and use its code and secrets | Each run has a time limit |
| Operating system scheduler | A computer you control runs a script at a set time | Long jobs, and jobs that need local files or tools | The machine must be on, and someone must own it |
A CI runner. Our Docket Scraper is a Node script that runs on GitHub Actions. It checks public court records on a schedule and reports what changed. It runs on a free CI runner, and there is no server to maintain.
A hosting platform's scheduler. Firm Mail Intake, which reads a law firm's incoming email, runs on Vercel Cron. A platform scheduler suits a job like this because the scheduled function lives in the same project as the rest of the tool.
The operating system's scheduler. Our Content Engine publishes a daily article using Windows Task Scheduler to start a script each morning. The engine is a set of Python and PowerShell scripts on a machine we control, so the local scheduler is the simple answer.
What kinds of work belong on a schedule?
Work belongs on a schedule when it needs to happen regularly and nobody needs the result instantly. Checking for changes, applying queued updates, sending digests, publishing prepared content, and cleaning up old data are all good fits. Anything a user is waiting on should run immediately instead.
Examples from our own projects:
- Checking for changes. Court dockets, as above.
- Applying staged edits. On RankAZona, business owners edit their own profile through an emailed link. Edits are staged, verified, and applied on a schedule, not written straight to the live page.
- Publishing. The RankAZona news engine publishes every morning. We describe that pipeline in automated content publishing.
- Reading queues. New email, processed in batches.
Staging plus a schedule is a useful pattern on its own. It puts a checkpoint between "someone submitted something" and "it is live", which is where verification happens.
How do you make a scheduled job reliable?
Make a scheduled job reliable by designing it so that running twice does no harm, a failed run tells someone, and a missed run is caught up next time. A scheduler starts jobs. It does not check that they succeeded.
Our rules:
- Safe to run twice. Track what has been processed. If the job starts twice, the second run finds nothing to do.
- Fail loudly. A job that fails should send an alert. A job that finds nothing should say so in its log, so silence is never ambiguous.
- Catch up. Ask for "everything since the last successful run", not "everything from the last hour". Then a skipped run costs nothing.
- Stay inside the time limit. Hosted schedulers stop long jobs. Process in batches.
- Keep secrets out of the code. Credentials belong in the platform's secret store, as covered in environment variables and secrets.
- Write down who owns it. A scheduled job nobody remembers is a future outage.
Frequently asked questions
Do I need my own server to run a cron job?
No. CI services and hosting platforms will run scheduled jobs for you, and nothing stays switched on between runs. Our Docket Scraper has no server at all. A dedicated machine only makes sense for long jobs or ones that need local resources.
What happens if a cron job fails?
By default, nothing. The scheduler does not retry or tell anyone unless you set that up. That is why every scheduled job needs its own alerting and a way to pick up missed work on the next run.
How often can a cron job run?
Standard cron goes down to once a minute. Hosted schedulers may set their own minimum interval depending on the plan, so check the platform's documentation. If you need something faster than a minute, you want an event or a queue, not a schedule.
Is a cron job the same as a webhook?
No. A cron job runs at a set time. A webhook runs when another system sends a message that something happened.
If part of your business depends on someone remembering to run something, it probably belongs on a schedule. Tell us what it is and we will suggest the simplest place to run it.