Cron jobs run the quiet work behind websites and servers: backups, updates, imports, invoices, cache warm-ups and cleanups. When they work, nobody notices. When they stop, nobody notices either, until a backup is missing or an invoice run never happened.
Why cron jobs matter
Cron schedules commands to run automatically at fixed times or intervals. That saves time and removes the risk of someone forgetting a task. It also means critical work, like nightly backups, depends on a scheduler that tells nobody when something goes wrong.
Common reasons for missed cron jobs
- Server downtime. If the server is off or rebooting at the scheduled time, the job does not run.
- Syntax errors. A wrong field in the schedule expression can mean the job runs at the wrong time or never.
- Misconfiguration. Wrong user, wrong working directory or a job added to a crontab that is never loaded.
- Environment differences. Cron runs with a minimal environment. A command that works in your shell can fail under cron because
PATHor other variables are missing. - Overlaps and timeouts. A job that runs longer than its interval can collide with the next run. A maximum run time on the job’s monitor tells you when a run takes too long.
Identifying and troubleshooting errors
Start with the logs. The system log (often /var/log/syslog or the cron log on your distribution) shows whether cron started the job. Your job’s own output shows what happened next.
Typical errors and what they mean:
- command not found: use absolute paths, or set
PATHat the top of the crontab. - permission denied: check file permissions and which user the job runs as.
- syntax error: check the schedule expression and quoting in the command.
Redirect output to a log file so failures leave a trace:
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1Monitoring cron jobs
Logs only help if someone reads them. Monitoring turns a silent failure into an alert. The most reliable way is a heartbeat: the job sends a request to a monitoring URL when it finishes. If the request does not arrive within the expected time, you get an alert.
With Uptimecheck cron monitors, the job pings a unique URL with GET or POST. The monitor takes the crontab schedule in your time zone, accepts start and finish pings on one monitor, alerts when a run exceeds its maximum run time, and can record the exit code and the job’s output. If a ping is missing, the alert goes to email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, a webhook or push notifications on your phone, on every plan. Read the step-by-step guide in How to monitor cron jobs.
Best practices for scheduling
- Schedule heavy jobs outside peak hours.
- Stagger jobs that use the same resources instead of starting them all at midnight.
- Use a lock (for example
flock) so a slow run does not overlap the next one. - Review schedules when your application changes.
Running cron across several servers
When the same job exists on several servers, decide where it should run and make sure it runs once. Central scheduling or a lock in a shared store helps. Give each job its own heartbeat, so you know which server missed its run.
Securing cron jobs
Cron jobs often have access to databases, backups and credentials.
- Limit who can edit crontabs.
- Keep secrets out of the crontab line itself and in protected files or environment configuration.
- Review jobs regularly and remove the ones you no longer need.
Using resources efficiently
Run jobs only as often as they need to run, and keep the commands lean. A report that nobody reads hourly can run daily.
Test before you rely on it
Run a new job by hand under the same user, check the output and only then schedule it. Add the heartbeat at the same time, so you know from the first night whether it ran.
Conclusion
Cron jobs are essential and invisible, which is exactly why they need monitoring. Fix the common causes, log the output and add a heartbeat to every job that matters.
Try Uptimecheck free for 14 days, no credit card required.