If you're not sure whether your WordPress backups are actually running, the honest answer is that most people find out something's wrong only when they need a backup and it isn't there — because WordPress's default scheduling system, wp-cron, only fires when a page on your site is visited. On a low-traffic site, that means scheduled tasks including backups can silently stop running for weeks without any error appearing anywhere. Here's how to check what's actually happened, and how to fix it so it can't happen again.

Symptoms

  • Your backup plugin's dashboard shows a schedule (e.g., "daily" or "weekly"), but you can't remember the last time you actually looked at whether it ran.
  • When you check the backup history/log, the most recent successful backup is noticeably older than the schedule implies.
  • The site had very little traffic over a stretch of days or weeks (a holiday, a slow period, a staging/low-priority site).
  • You've never actually tested restoring from one of the backups this plugin produced.

Likely causes, in order of how often they actually happen

  1. wp-cron never fires because nothing visits the site. WordPress's built-in "cron" isn't a real system cron job — it's a virtual scheduler that only checks whether any scheduled task is due when a page loads. If no one visits the site (common on low-traffic blogs, internal tools, or staging sites), no scheduled task runs, including your backup plugin's job, regardless of what schedule you set in its settings.
  2. wp-cron is disabled or throttled without your knowledge. Some performance plugins, security plugins, or hosting configurations disable WordPress's default cron behavior (by setting DISABLE_WP_CRON to true) as a performance optimization, expecting a real server-level cron job to be configured instead — and that real cron job was never actually set up.
  3. The backup plugin's own schedule silently failed or was reset, for instance after a plugin update, a site migration, or a change in scheduled backup settings that didn't save correctly the way you expected.
  4. You're assuming a backup ran because the plugin says it's scheduled, without ever actually opening its history/log to confirm — the schedule shown in a plugin's settings screen only tells you the intent, not what actually executed.

Fix it: lowest-risk steps first

Step 1 — Check your backup plugin's own history log directly

Don't rely on the schedule setting — go straight to the record of what actually happened.

  1. Open your backup plugin's dashboard (WPvivid's All Backups list, UpdraftPlus's backup log, Duplicator Pro's schedule history, or the equivalent screen for whichever plugin you use) and find the list of completed backups with timestamps.
  2. Compare the most recent entry's date against what your configured schedule promises (daily, weekly, etc.). A meaningful gap confirms the problem is real, not hypothetical.
  3. If backups look current, you likely don't have this problem — but it's still worth doing Step 2 to confirm wp-cron is healthy going forward, since a gap can start at any time.

Step 2 — Install WP Crontrol to see scheduled vs. actually-run events

WP Crontrol is a free, widely-used plugin that gives you direct visibility into WordPress's cron system, which your backup plugin's own dashboard doesn't show.

  1. Install and activate WP Crontrol from the Plugins → Add New screen.
  2. Go to Tools → Cron Events. This lists every scheduled task WordPress knows about, including your backup plugin's job, with its next scheduled run time.
  3. Look for your backup plugin's event in the list. If its "Next Run" time is in the past (rather than upcoming), that's a strong signal wp-cron isn't firing reliably — a healthy cron system processes overdue events the next time any page loads, so an event that's been overdue for a while confirms nothing is triggering it.
  4. WP Crontrol also lets you manually run any listed event immediately (via the "Run Now" link) — useful for confirming the backup plugin's job still works correctly when actually triggered, isolating whether the problem is the schedule itself or something wrong with the backup task.

Step 3 — Check whether wp-cron has been disabled

  1. If you have access to wp-config.php, search it for the line define('DISABLE_WP_CRON', true);. If present, WordPress's default page-load-triggered cron is turned off entirely, and something needs to be triggering it another way (see Step 4) — this line is sometimes added by caching or performance plugins/hosts without clearly explaining that a real cron job is expected to replace it.
  2. If you don't see this line, wp-cron is theoretically active, but still entirely dependent on site visits per cause #1 — which is exactly what Step 4 fixes regardless of which scenario you're in.

Step 4 — Set up a real server-level cron job to trigger wp-cron

This is the permanent fix, and it works whether or not DISABLE_WP_CRON is set — a real cron job simply becomes the reliable trigger instead of depending on visitor traffic.

  1. In your hosting control panel (cPanel's "Cron Jobs" section, aaPanel's "Cron" section, or your host's equivalent), create a new scheduled task.
  2. Set it to run at a reasonable interval — every 15 minutes is a common, safe default for most sites; busier backup schedules may warrant more frequent triggers.
  3. The task should call wp-cron.php directly. Most panels let you either run a curl or wget command against your site's wp-cron.php URL (e.g., curl https://yoursite.com/wp-cron.php), or in some panels, run the WP-CLI equivalent (wp cron event run --due-now) if WP-CLI is available on your hosting account. Use whichever method your host's cron interface supports.
  4. If you added DISABLE_WP_CRON in Step 3, leave it in place once the real cron job is set up — this is the correct end-state: a reliable server cron trigger instead of relying on page loads, which also reduces unnecessary load on every page view.
  5. After 24–48 hours, go back to WP Crontrol's Tools → Cron Events and confirm your backup plugin's job now shows a "Next Run" time consistent with its schedule, with no events stuck overdue.

Verify the fix

  1. In WP Crontrol, confirm scheduled events (including the backup plugin's job) show upcoming run times rather than overdue ones.
  2. Check your backup plugin's history log again after the next expected backup window and confirm a new entry appears with a current timestamp.
  3. Manually download or spot-check the most recent backup file to confirm it's a real, complete file — not just a log entry.

If you need to roll back

Setting up a server-level cron job and confirming wp-cron's status doesn't change anything risky about the live site — if you're not comfortable with the server cron job you configured, simply delete it from your hosting panel and, if you'd added DISABLE_WP_CRON in wp-config.php, remove or comment out that line to return to WordPress's default page-load-triggered behavior. Nothing here affects existing site content or the database.

Related fixes

FAQ

How often should a server-level cron job hit wp-cron.php?

Every 15 minutes is a reasonable default for most sites, balancing timeliness against unnecessary load. If your backup schedule or other scheduled tasks need finer timing, 5-minute intervals are common too — just avoid intervals so short they add meaningful load to a busy site.

Will disabling the default wp-cron behavior break anything else?

No, as long as you replace it with a real server cron job that hits wp-cron.php on a regular interval — WordPress's scheduled tasks (backups, publishing scheduled posts, plugin update checks, etc.) all still fire, just triggered reliably by the server instead of unreliably by visitor traffic. This is a standard, widely-recommended setup for exactly this reason.

My host doesn't offer a cron job feature — what else can I do?

Some backup plugins and monitoring services offer an external "uptime" or "ping" service that hits your site's URL on a schedule, which can trigger wp-cron the same way a visitor would, as a workaround. It's less reliable than a true server-level cron job, but it's better than depending entirely on organic traffic — check with your host first, though, since most hosting panels do include some form of cron job scheduling even on shared plans.