What Is a Cron Job?
A cron job is a task scheduled to run automatically at set times on a server, without anyone triggering it manually. The name comes from cron, a time-based job scheduler built into Unix and Linux systems. You define when a job runs — every night at 2 a.m., or every Monday — and the server runs the command on that schedule. Websites use cron jobs to automate backups, send emails, clear caches, generate reports, and sync data on a reliable timer.
- Name origin
- From 'cron,' the time-based job scheduler in Unix/Linux (crontab)
- Defined by
- A crontab entry with five time fields plus the command to run
- Typical uses
- Backups, scheduled emails, cache clearing, report generation, data syncs
- WordPress note
- WP-Cron is triggered by site traffic, not the system clock (WordPress.org)
- Alternatives
- systemd timers and cloud schedulers do the same job on newer stacks
What a cron job is #
A cron job is simply a command your server runs automatically on a schedule you set, with no human pressing a button. The scheduler behind it, called cron, has been part of Unix and Linux systems for decades and runs continuously in the background, checking the clock and launching any task whose time has come. You tell it two things: when to run and what to run. 'When' can be as coarse as once a day or as fine as every minute; 'what' is any command or script — back up the database, send pending emails, rebuild a cache, pull fresh data from a supplier. Once set, the job repeats faithfully until you remove it, which is exactly what you want for routine chores that must happen whether or not anyone remembers. Most business websites rely on several cron jobs quietly keeping things tidy. If your site is hosted on a proper server, these are already part of the picture. Our /services/managed-hosting page covers how we set up and maintain scheduled tasks on the servers we run.
How cron scheduling syntax works #
A crontab entry has five time fields — minute, hour, day of month, month, day of week — followed by the command. An asterisk means 'every.' Here are common examples.
# fields: minute hour day-of-month month day-of-week command
0 2 * * * /usr/bin/php /var/www/backup.php # daily at 2:00 AM
*/15 * * * * /usr/bin/php /var/www/sync.php # every 15 minutes
0 9 * * 1 /usr/bin/php /var/www/weekly-report.php # Mondays at 9 AMWhat businesses use cron jobs for #
Cron jobs handle the unglamorous, recurring work that keeps a website healthy. The most important is backups: a nightly job that copies your database and files means that if something breaks, you can restore yesterday's version instead of losing everything. Scheduled emails are another staple — appointment reminders, abandoned-cart nudges, weekly newsletters, and receipts often go out via timed jobs. Caches and temporary files get cleared on a schedule so the site stays fast and disks do not fill. Data synchronization is common too: pulling updated prices from a supplier, pushing orders to accounting software, or refreshing inventory counts every few minutes. Reports — sales summaries, analytics digests — are generated overnight so they are ready each morning. Even routine maintenance like renewing security certificates or pruning old logs runs on cron. For a small business, these automations replace hours of manual work and reduce human error. Our /services/care-plans and /services/database-services cover setting up backups and scheduled maintenance so this quiet, essential work happens without you thinking about it.
WordPress and WP-Cron #
WordPress deserves special mention because its scheduling works differently from true cron, and the difference causes real confusion. WordPress has its own system called WP-Cron that handles scheduled tasks like publishing posts, checking for updates, and running plugin jobs. The catch is that WP-Cron is not driven by the server's clock — it only runs when someone visits your site. On a busy site that is fine, but on a low-traffic site, scheduled tasks can be delayed or skipped entirely because no visitor triggered them, so that scheduled post never goes out. Conversely, on a very busy site WP-Cron can fire too often and waste resources. The standard fix is to disable WP-Cron's traffic-based triggering and instead call it from a real system cron job at a fixed interval, giving reliable, predictable timing. This is a routine optimization on well-managed WordPress sites. If your scheduled posts or plugin tasks behave unpredictably, this is often why. Our /services/wordpress-development team configures WP-Cron correctly so your timed tasks run on schedule rather than at the mercy of traffic.
Cron vs modern schedulers #
Classic cron is not the only way to schedule server tasks anymore, and knowing the alternatives helps you understand different hosting setups. On modern Linux systems, systemd timers do a similar job with more flexibility — they can handle missed runs after a reboot, log output cleanly, and express complex schedules. In cloud environments, managed schedulers like cron triggers in serverless platforms run your task without you maintaining a server at all, which suits sites built on cloud infrastructure. Application frameworks often ship their own schedulers layered on top of cron for convenience. Container platforms have their own scheduled-job features too. None of these replaces the core idea — run this task at these times — they just package it differently to fit the environment. For most business websites the underlying mechanism matters less than that scheduled tasks run reliably and someone monitors them. Our /services/vps-cloud-setup team chooses the scheduler that fits your stack, whether that is traditional cron on a server or a managed trigger in the cloud, so your automation is dependable regardless of the technology underneath.
Common cron job problems #
Cron is reliable, but its failures are notoriously silent, which is the biggest trap. Because a cron job runs unattended in the background, a job that breaks often produces no visible error — the backup simply stops happening and nobody notices until they need it. Common causes include wrong file paths, since cron runs with a minimal environment that may not know where a program lives; incorrect permissions; a script that works when you run it by hand but fails in cron's stripped-down context; and time-zone confusion, where a job set for 2 a.m. runs at an unexpected hour on a server in another region. Overlapping runs are another issue — if a job takes longer than its interval, a second copy can start before the first finishes, causing conflicts. The remedies are using full paths, testing in cron's actual environment, and adding logging so you can see what happened. Silent failure is precisely why monitoring matters. Our /services/managed-hosting team sets up cron jobs with proper paths, logging, and alerts so a failed task does not go unnoticed for weeks.
Security and reliability considerations #
Because cron jobs run automatically with server privileges, they deserve careful handling. A job runs as whatever user owns it, so a task running with excessive privileges is a risk if the script it calls is ever compromised — the principle of least privilege applies here just as it does to credentials. Scripts triggered by cron should be stored where web visitors cannot reach or execute them directly, and any secrets they use, like API keys or database passwords, should be kept out of the script itself and in protected configuration. Reliability matters as much as security: a backup job that fails silently is worse than none, because it breeds false confidence. Best practice pairs each important job with logging and an alert that fires if the job does not complete, sometimes using a 'dead man's switch' service that expects a check-in and warns you when it goes missing. Together these turn cron from a set-and-forget gamble into dependable automation. Our /services/website-security team reviews scheduled tasks so they run with least privilege and their failures are actually noticed.
Do you need cron jobs? #
If you run any dynamic website, you almost certainly already depend on cron jobs even if you have never heard the term. Automatic backups, scheduled emails, cache clearing, and data syncs all typically run on a schedule behind the scenes. The practical question is not whether to have them but whether yours are set up correctly and monitored. A few honest checks help: Are your backups actually running and being tested by restoring them occasionally? Do scheduled emails and posts go out on time? Does someone get alerted if a job fails? Many small-business sites have cron jobs that quietly stopped working months ago, discovered only during an emergency. You do not need to manage crontabs yourself; you need confidence that this automation is reliable. If you are unsure whether your backups and scheduled tasks are healthy, a /free-website-audit can check, and our /services/managed-hosting service includes setting up and watching these jobs so the routine work never silently lapses when you most need it.
Monitoring scheduled tasks #
The single most valuable habit with cron jobs is monitoring, because their defining weakness is silent failure. A job that stops running rarely announces itself; the missing backup or unsent report is discovered only when it is needed and absent. Good monitoring closes that gap in a few ways. Logging each run's output and exit status gives you a record to inspect when something looks off. Alerting on failure sends an email or message the moment a job errors, so you learn immediately rather than weeks later. A widely used pattern is a heartbeat or dead-man's-switch: the job 'checks in' with a monitoring service each time it succeeds, and if the expected check-in never arrives, the service alerts you — catching not just errors but jobs that failed to run at all. Periodically testing that backups actually restore closes the loop, since an untested backup is only a hope. This monitoring is what separates real reliability from assumed reliability. Our /services/care-plans include watching your scheduled tasks and backups so a lapsed job is caught quickly, not during a crisis.
FAQ
What does 'cron' stand for?
Cron is not an acronym; the name is generally traced to 'chronos,' the Greek word for time, reflecting its role as a time-based scheduler. It has been part of Unix and Linux systems since the 1970s and remains the standard tool for running commands automatically at scheduled intervals on a server.
Why is my WordPress scheduled post not publishing?
WordPress uses WP-Cron, which runs only when someone visits your site rather than on the server clock. On a low-traffic site, no visitor may trigger it at the right moment, so scheduled posts get delayed or skipped. The fix is to disable traffic-based WP-Cron and call it from a real system cron job at fixed intervals.
How often can a cron job run?
Standard cron can run a job as frequently as once per minute, which is the finest interval its syntax expresses. For tasks needing to run more often than that, developers loop within a single job or use other schedulers. Common schedules are every few minutes for syncs and once nightly for backups and reports.
Why did my cron job stop working silently?
Cron jobs run unattended, so failures often produce no visible error. Frequent causes are wrong file paths, since cron uses a minimal environment, incorrect permissions, missing environment variables, or time-zone confusion. Because they fail quietly, important jobs need logging and failure alerts so you learn about problems promptly instead of during an emergency.
Are cron jobs safe?
They are safe when configured with care. Because they run automatically with server privileges, jobs should use the least privilege needed, keep scripts out of publicly reachable folders, and store secrets in protected configuration rather than in the script. Pairing them with logging and failure alerts also ensures a compromised or broken job is noticed quickly.
Do I need to manage cron jobs myself?
No. On managed hosting or a care plan, your provider sets up and monitors scheduled tasks like backups and emails for you. What matters is confirming those jobs exist, run on time, and are watched for failure. If you are unsure yours are healthy, an audit can verify your backups and scheduled tasks are actually running.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?