Cronjob: What It Is, How to Write One, and Why It Fails
August 28, 2026
What Is a Cronjob?
A cronjob is a task scheduled to run automatically at a fixed time or interval, without a human triggering it. Cron is the daemon — a background service built into virtually every Unix-like operating system that wakes up every minute, checks a schedule, and fires off whatever tasks are due. A cronjob is one entry in that schedule: the specific command or script paired with a time expression telling cron when to run it. The cron daemon is the engine; the cronjob is the instruction you give it.
You'll sometimes see "cron job" written as two words and "cronjob" as one — there's no real distinction; they mean the same thing.
In practice, cronjobs handle the repetitive work nobody wants to do by hand:
- Database backups run nightly so you always have a recent snapshot.
- Report emails get generated and sent every Monday morning.
- Data syncs pull or push records between systems on a fixed interval.
- Cleanup scripts purge old logs, temp files, or expired sessions.
These jobs are simple to set up and easy to forget about — which is exactly where the trouble starts later in this guide.
Cronjob Syntax: How the Schedule Actually Works
Cron schedule expressions look cryptic at first, but the crontab syntax is just five fields, each representing a unit of time, followed by the command to run.
| Field | Allowed values | Meaning |
|---|---|---|
| Minute | 0-59 | Minute of the hour |
| Hour | 0-23 | Hour of the day (24-hour clock) |
| Day of month | 1-31 | Day of the month |
| Month | 1-12 | Month of the year |
| Day of week | 0-6 (0 = Sunday) | Day of the week |
A full line looks like: minute hour day-of-month month day-of-week command.
A few special characters do most of the heavy lifting:
*means "every value" for that field./sets a step, e.g.*/5means "every 5 units.",lists multiple discrete values, e.g.1,15for the 1st and 15th.-defines a range, e.g.9-17for hours 9 through 5pm.
Once you can read those symbols, almost any cron schedule expression becomes decipherable at a glance.
Cronjob Examples You Can Copy
Here are ready-to-use cronjob examples covering the patterns most teams actually need:
*/5 * * * *— runs every 5 minutes, all day, every day. Good for lightweight polling tasks.0 0 * * *— runs daily at midnight. The classic nightly backup slot.0 9 * * 1-5— runs at 9am on weekdays only. Ideal for business reports.0 0 1 * *— runs at midnight on the 1st of every month. Common for monthly billing or archiving jobs.*/15 9-17 * * 1-5— runs every 15 minutes, 9am–5pm, weekdays. A tight monitoring or sync window during business hours.30 2 * * 0— runs at 2:30am every Sunday. Useful for weekly maintenance that shouldn't collide with weekday traffic.
These examples cover the vast majority of real scheduling needs — adjust the numbers, keep the structure.
Where You Actually Set Up a Cronjob
The most common way to schedule a cron job on a Linux server is crontab -e, which opens your personal crontab file in an editor — each line follows the syntax above. There's also a system-wide crontab (typically /etc/crontab or files under /etc/cron.d/) for jobs that should run regardless of which user is logged in.
Outside a single server, cronjobs show up in other places. A Docker cronjob usually runs cron inside a container image, or more commonly, a lightweight scheduler process runs alongside the container to trigger tasks. Cloud platforms (AWS EventBridge, GCP Cloud Scheduler, and similar) offer managed schedulers that skip the server entirely and call an HTTP endpoint on a timer — increasingly how modern scheduled jobs are actually run.
If you're weighing whether to manage schedules by hand in a crontab file versus using a dashboard that shows you what's running and what isn't, Cron UI Explained: Crontab Editor vs. Monitoring Dashboard walks through the tradeoffs.
Why Cronjobs Fail Silently
Here's the part most "what is a cronjob" guides skip: a cronjob that's scheduled correctly and one that's actually working are two different claims, and cron gives you almost no help telling them apart.
A few of the most common ways a cron job fails silently:
- No mail transfer agent installed. Cron traditionally emails command output to the local user, but most modern servers don't have a mail system configured — so any error output just disappears. This exact scenario is covered in Fix "Cron No MTA Installed, Discarding Output".
- A server reboot that never brings cron or the job's dependencies back up cleanly.
- A deploy that overwrites the crontab, quietly removing a job that used to run fine.
- Network timeouts on an HTTP call inside the script, which the script doesn't catch or retry.
- Non-zero exit codes that go unchecked, so the job technically "runs" every time but has been failing internally for weeks.
In every one of these cases, cron isn't broken — it faithfully fires the command on schedule. If the command itself fails or the environment underneath it changes, there's no cronjob troubleshooting alert waiting for you. You find out about a cronjob not running the same way most teams do: someone notices the backup is missing, or a customer complains the report never arrived.
How to Actually Know a Cronjob Succeeded
The only reliable fix is to have the job report back when it finishes — a completion ping, or heartbeat, sent to a monitoring service after each run. If the expected ping doesn't arrive on schedule, the monitoring service raises the alert instead of leaving that job to fail in silence. This is the core idea behind cron job monitoring: you stop trusting that "scheduled" equals "working" and start verifying it on every run.
This is exactly the gap Cronevra is built to close — you point your cronjob at a Cronevra endpoint (or have it ping back after execution), and cronjob alerts fire the moment a run is late, missing, or reports failure. For the mechanics of how that ping actually works, see API Ping Explained: Pull vs Push Monitoring for Cron Jobs. Once you're monitoring jobs, the next tuning step is avoiding noisy false alarms — covered in Grace Timers Explained: Tuning Cron Alerts That Matter. And if you want the broader case for why "it ran" isn't good enough, Why Are API Health Checks Useful? The Real Payoff makes that argument in more depth.
Understanding cron syntax gets your job scheduled. Monitoring is what tells you it's actually doing its job. Rather than finding out about a missed run from a customer complaint, add your first cronjob to Cronevra in a couple of minutes and let alerts do the watching — check the pricing page to see what fits your team.
Frequently Asked Questions
What is a cronjob in simple terms?
A cronjob is a scheduled task that runs automatically at a set time or interval, managed by the cron daemon on Unix-like systems. You define when it should run using a five-field time expression, and cron handles triggering it — no human needs to click "run."
What's the difference between cron and a cronjob?
Cron is the background service (daemon) that checks scheduled tasks every minute and runs the ones that are due. A cronjob is one specific scheduled task — the command plus its timing — that cron executes; cron is the engine, the cronjob is the instruction.
How do I write a cron schedule expression?
A cron schedule expression has five fields in order: minute, hour, day of month, month, and day of week, followed by the command. Use * for "every value," / for step intervals, , for lists, and - for ranges — for example, */15 9-17 * * 1-5 runs every 15 minutes during business hours on weekdays.
Why did my cronjob stop running with no error message?
The most common causes are a missing mail transfer agent that discards output, a server reboot that didn't restore the job's environment, a deploy that overwrote the crontab, or a network timeout inside the script that was never caught. Cron itself keeps working fine in all these cases — it's the job or its environment that quietly broke.
Can a cronjob run more often than once a minute?
No — standard cron resolution is one minute, so * * * * * is the fastest a single cron entry can trigger. For sub-minute frequency, you'd need multiple staggered entries or a different scheduling tool designed for finer intervals.
How do I know if my cronjob actually succeeded, not just ran?
You need the job to report back after it finishes, typically via a completion ping or heartbeat sent to a monitoring service. If the expected ping doesn't arrive on time, or the job reports a failure exit code, the monitoring service alerts you — turning a silent failure into an immediate notification.