Cron jobs explained for non-developers — and why they break

What’s a cron job?

A cron job is a small scheduled task that runs automatically on a schedule. The name comes from the Unix utility called cron that runs them. The schedule can be anything — every minute, every hour, every Tuesday at 3 AM, the first of every month at midnight.

Modern websites have lots of these running in the background. You usually don’t see them. They quietly do their work — usually — until something breaks.

Common examples on a typical small business site:

• Database backups — runs nightly, dumps the database to a file
• Send abandoned cart emails — runs every 4 hours, emails customers who didn’t check out
• Clean up expired sessions — runs hourly, removes old session data
• Sync inventory with a supplier — runs every 30 minutes, pulls stock levels
• Generate weekly reports — runs Monday morning, emails you a summary
• Renew SSL certificates — runs every 60 days, refreshes Let’s Encrypt
• Charge subscriptions — runs daily, bills monthly subscribers
• Compress old log files — runs weekly, manages disk space

If you’re on WordPress, the system equivalent is called WP-Cron. It does essentially the same thing — runs tasks on a schedule.

Why cron jobs are invisible (and why that’s a problem)

The whole point of a scheduled task is that it runs without you thinking about it. That’s also exactly why broken cron jobs are so dangerous — there’s no UI lighting up red, no error message on the homepage, no immediate signal.

A typical broken cron job timeline:

1. Day 0: Cron job stops working. Maybe a permissions change, maybe a server move, maybe the underlying script broke after a deploy.
2. Day 1: Backup didn’t run last night. Nobody notices because backups are silent.
3. Day 3: Inventory sync hasn’t run. The site shows stock levels that are 72 hours stale. Customers buy things that are out of stock.
4. Day 7: Weekly report didn’t arrive Monday morning. You don’t notice — you forgot you had it set up.
5. Day 30: SSL renewal didn’t happen. Cert expires. Site goes down. Now you find out.

The dangerous category isn’t the jobs that fail loudly. It’s the jobs that succeed silently when they should have run but didn’t. Distinguishing those two cases is the whole job of cron monitoring.

How cron jobs go wrong

The common failure modes:

1. The job script broke. A recent code change introduced a bug. The cron triggers the script; the script errors out and exits. Cron logs the failure but most people don’t look at cron logs.

2. The job is taking too long. The job started but is still running when the next scheduled run begins. Now you have two copies running, fighting over the same database, locking each other out.

3. The cron daemon isn’t running. The system service that triggers cron jobs is down. None of the scheduled tasks fire. Nothing else looks broken.

4. The job’s environment changed. A path changed, a permission changed, an API key expired. The job runs in a different context than the one in which it was tested, and silently fails.

5. WP-Cron stops triggering. WordPress’s built-in cron only fires when a page is loaded. On a low-traffic site, it might not fire often enough — or at all — to run scheduled tasks.

6. The job runs but does nothing useful. A backup that “succeeds” by writing an empty file. An email job that runs but the SMTP credentials expired. The cron itself is fine; the underlying task is broken.

Each of these is invisible from outside. Your uptime monitor is green; your homepage is up; your cron jobs are broken.

What “cron monitoring” actually does

Cron monitoring is a clever inversion: instead of monitoring the job itself, you monitor the absence of expected check-ins.

Here’s how it works:

1. You tell the monitoring service “I have a job that should run every hour.”
2. The service generates a unique URL for that job.
3. Inside the job, after it completes successfully, you make a simple HTTP request to that URL.
4. The monitoring service expects that ping every hour. If more than 70 minutes pass without a ping, the service alerts.

The key insight: the monitoring isn’t tied to the cron daemon, the script, or the server. It’s based on whether the expected outcome (a successful ping) happens on schedule. If anything in the chain breaks — cron daemon, script, server, network — the ping doesn’t arrive, and you find out.

This is what Healthchecks.io, Cronitor, and Dead Man’s Snitch do as dedicated products. Some uptime services include it as a feature.

A working example

Let’s say you have a nightly backup script:

#!/bin/bash
# /opt/backups/run-backup.sh

pg_dump mydatabase > /backups/db-$(date +%F).sql
aws s3 cp /backups/db-$(date +%F).sql s3://my-backups/

# Ping the monitoring service to say "this ran successfully"
curl -fsS --retry 3 https://hc-ping.com/abc123 > /dev/null

Note the ping at the end. It only fires if the script reached that point — if pg_dump or aws s3 cp failed, the script exits before the curl, the ping doesn’t happen, and the monitor alerts.

You can get even fancier:

#!/bin/bash

# Tell the service we're starting
curl -fsS https://hc-ping.com/abc123/start > /dev/null

# Run the actual job
if ! pg_dump mydatabase > /backups/db.sql; then
  curl -fsS https://hc-ping.com/abc123/fail > /dev/null
  exit 1
fi

if ! aws s3 cp /backups/db.sql s3://my-backups/; then
  curl -fsS https://hc-ping.com/abc123/fail > /dev/null
  exit 1
fi

# Success
curl -fsS https://hc-ping.com/abc123 > /dev/null

Now the monitoring service tracks:

• Did the job start when expected?
• Did it explicitly fail?
• Did it complete successfully?

If any expected step is missing, you get an alert with context.

Cron monitoring vs. uptime monitoring

The two complement each other:

• Uptime monitoring checks “is the website reachable from outside right now?”
• Cron monitoring checks “did my scheduled tasks run when they were supposed to?”

The same monitoring service often provides both. The key thing is that you need both kinds of checks because they catch different categories of failure. A site with no uptime monitoring is blind to outages. A site with no cron monitoring is blind to all the background processes that quietly keep the business running.

For most small businesses, the cron jobs that matter most are:

• Backups
• Billing / payment processing
• Anything that emails customers (digests, abandoned cart, password resets)
• SSL renewals
• Anything that syncs data between systems

If you don’t know which scheduled tasks exist on your site, that itself is worth investigating — ask whoever set up the site or check your hosting control panel.

Common WordPress quirks

WordPress has a unique cron situation worth knowing about:

WP-Cron only runs when someone visits the site. It’s not a true cron in the system sense — it’s a list of tasks that get checked on every page load. If your site has lots of traffic, this works fine. If you have a low-traffic site, scheduled tasks may not run on time, or at all.

The fix is to disable WP-Cron and run a real system cron that pings WordPress’s cron endpoint:

// In wp-config.php
define('DISABLE_WP_CRON', true);

# In your system crontab
*/15 * * * * curl -s https://yoursite.com/wp-cron.php > /dev/null

Most managed WordPress hosts do this automatically. If you’re on cheap shared hosting, it’s worth checking whether WP-Cron is actually firing — a free monitoring service can help here.

Plugin cron jobs. Many plugins register their own scheduled tasks via WP-Cron. If WP-Cron isn’t running properly, these all stop too. The plugin doesn’t know — it just stops doing the thing it’s supposed to do.

What you can do today

If you’ve read this far and don’t know if your scheduled tasks are running:

1. List them. Make a list of every scheduled task on your site. Backups, emails, integrations, billing, whatever. If you can’t find a list, ask your developer or check your hosting dashboard.
2. Identify the critical ones. Of that list, which would matter most if it stopped working? Usually: backups, billing, customer emails.
3. Add cron monitoring to those. Free tier services like Healthchecks.io cover 20 cron jobs for free; some uptime monitoring services include it. You add the monitoring URL into the script, and you get an alert when the expected ping doesn’t arrive.
4. Add log monitoring for the rest. At minimum, your cron logs should be checked weekly. Most systems email cron output to root if not redirected — at least make sure root’s email goes somewhere you’ll read.

Total time investment: an afternoon. Return: knowing whether the silent automation that runs your business is actually working.

What we do, briefly

MyUptimeBot is currently focused on uptime monitoring rather than cron monitoring — those are adjacent products with slightly different needs. For cron monitoring specifically, Healthchecks.io is excellent (and open-source if you want to self-host). Cronitor is another solid option.

The point isn’t which service you use. It’s that scheduled tasks are too easy to forget and too easy to break silently. A few minutes of setup gives you visibility into the part of your site that’s specifically designed to be invisible — and that’s where some of the most painful outages hide.