{"id":74647,"date":"2026-07-02T07:49:49","date_gmt":"2026-07-02T13:49:49","guid":{"rendered":"https:\/\/www.scalahosting.com\/blog\/?p=74647"},"modified":"2026-07-02T07:49:50","modified_gmt":"2026-07-02T13:49:50","slug":"wordpress-cron-jobs","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/blog\/wordpress-cron-jobs\/","title":{"rendered":"6 Useful Cron Jobs for WordPress Sites and When to Use Them"},"content":{"rendered":"\n

The scheduled blog post you queued for 9 AM Monday went live at 2 PM. Your daily database backup didn’t run last weekend. And the SSL certificate on your client’s site expired forty minutes before they noticed – by which point Google was already warning visitors away.<\/p>\n\n\n\n

Three different problems, same root cause: cron jobs that either weren’t set up, weren’t running, or weren’t running on time.<\/p>\n\n\n\n

WordPress depends on background work to function. Publishing scheduled posts, sending password reset emails, pruning expired data, checking for plugin updates – none of it happens by magic, and none of it happens reliably unless you tell it to. <\/p>\n\n\n\n

Below are six useful WordPress cron jobs to consider, with example syntax you can adjust and test before relying on it. Some are good fits for real Linux cron, while others may be better handled by SPanel\u2019s built-in WordPress Manager, account backups, or website monitoring.<\/p>\n\n\n\n

Why WordPress’s Default Cron Isn’t Enough<\/strong><\/h2>\n\n\n\n

WordPress has a built-in scheduler called wp-cron<\/strong>. It triggers scheduled tasks only when someone visits your site. On a high-traffic site, that’s fine – there’s always someone walking through the door. On a low-traffic site (or one that goes quiet overnight), tasks pile up and run hours late, if they run at all.<\/p>\n\n\n\n

That delay matters more than it sounds. Security updates, scheduled posts, transactional emails, plugin auto-updates, and integration syncs all sit in the wp-cron queue waiting for a trigger that may never come at the right time.<\/p>\n\n\n\n

Patchstack’s 2026 State of WordPress Security report<\/a> found 11,334 new WordPress vulnerabilities<\/strong> disclosed in 2025 – a 42% jump over the prior year – with 91% of them in plugins. The most uncomfortable finding: the median time from public disclosure to the first wave of exploitation attempts is five hours. If your plugin update schedule is “whenever wp-cron gets around to it,” you’re losing that race before you start.<\/p>\n\n\n\n

Real Linux cron solves this. It runs on a clock, not on visitor traffic. The six jobs below assume you’ve already moved off wp-cron – which is, conveniently, job number one.<\/p>\n\n\n\n

On ScalaHosting, you do not have to guess whether a cron job works. In SPanel\u2019s Cron Job Manager, you can add a job, run it immediately, and inspect the captured output before waiting for the scheduled time. New jobs are quiet by default because SPanel uses an empty MAILTO= setting, and every job runs under your hosting account user rather than root. For WordPress-specific work, SPanel also gives you WordPress Manager staging, updates, file locking, and account-level backups, so some maintenance tasks are better handled natively than through custom cron.<\/p>\n\n\n\n

The Six Cron Jobs Every WordPress Site Should Have<\/strong><\/h2>\n\n\n\n
\"6<\/figure>\n\n\n\n

Each entry uses standard cron syntax – five fields for the schedule (minute, hour, day of month, month, day of week), followed by the command. If you’re new to cron, crontab.guru<\/a> is the fastest way to translate a pattern into plain English.<\/p>\n\n\n\n

A note before the snippets: full command paths (like \/usr\/bin\/php vs. just php) vary by host. The snippets below use generic command names – if your environment requires absolute paths, your control panel or host documentation will list them.<\/p>\n\n\n\n

1. Replace wp-cron with Real Cron (Every 15 Minutes)<\/strong><\/h3>\n\n\n\n

The problem:<\/strong> wp-cron only fires on page visits, which is unreliable on low-traffic sites.<\/p>\n\n\n\n

The fix:<\/strong> two changes. First, disable wp-cron in wp-config.php by adding this line near the other define() statements:<\/p>\n\n\n\n

php
define(‘DISABLE_WP_CRON’, true);<\/p>\n\n\n\n

Then add this cron entry, replacing yourdomain.com with your actual domain:<\/p>\n\n\n\n

*\/15 * * * * wget -q -O – https:\/\/yourdomain.com\/wp-cron.php?doing_wp_cron >\/dev\/null 2>&1<\/p>\n\n\n\n

You can have cron send an email every time it runs a command which produces output. If you do not want an email to be sent for an individual cron job, you can redirect the command\u2019s output to \/dev\/null<\/em>. <\/p>\n\n\n\n

Why every 15 minutes:<\/strong> most WordPress scheduled tasks tolerate a 15-minute window without anyone noticing. More frequent is overkill; less frequent risks late post publishing or delayed transactional email.<\/p>\n\n\n\n

2. Daily Database Backup (Every Day, 2 AM)<\/strong><\/h3>\n\n\n\n

The problem:<\/strong> your database is the single most painful thing to lose. Themes and plugins can be reinstalled; user comments, orders, and content can’t.<\/p>\n\n\n\n

The cron entry:<\/strong><\/p>\n\n\n\n

0 2 * * * mysqldump -u DB_USER -pDB_PASS DB_NAME > \/home\/USER\/backups\/db-$(date +\\%Y\\%m\\%d).sql<\/p>\n\n\n\n

Replace the placeholders with your database password, your account username, and your database name. Make sure the backups\/ directory exists first.<\/p>\n\n\n\n

Note the escaped % signs. Cron treats % as a special character – you need backslashes in front of them, or the command silently breaks.<\/p>\n\n\n\n

Why daily, at 2 AM:<\/strong> quiet hours, before your other maintenance kicks in. Daily snapshots give you fine-grained recovery points on top of your host’s standard backups. They don’t replace your host’s backups; they complement them.<\/p>\n\n\n\n

3. Weekly Cleanup of Old Files and Expired Data (Sunday, 3 AM)<\/strong><\/h3>\n\n\n\n

The problem:<\/strong> WordPress sometimes accumulates badly designed or overly complicated code. Expired transients pile up in the database. Old backups from job #2 fill your disk. Neither cleans itself up.<\/p>\n\n\n\n

For pruning your local backup directory and keeping the last 30 days:<\/p>\n\n\n\n

0 3 * * 0 find \/home\/USER\/backups\/ -type f -mtime +30 -delete<\/p>\n\n\n\n

For expired transients in the database, the cleanest approach uses WP-CLI:<\/p>\n\n\n\n

0 3 * * 0 cd \/home\/USER\/public_html && wp transient delete –expired <\/p>\n\n\n\n

IMPORTANT<\/strong>: WP-CLI isn’t installed on every host. Our managed VPS plans ship with WP-CLI preinstalled, but on other environments, you may need to install it yourself – or replace the transient cleanup with a direct SQL query against the wp_options table.<\/p>\n\n\n\n

Why Sunday 3 AM:<\/strong> most sites are quietest then, and a weekly cleanup is plenty for any normal-traffic site.<\/p>\n\n\n\n

4. Daily Plugin Update Check (Every Day, 4 AM)<\/strong><\/h3>\n\n\n\n

The problem:<\/strong> plugins are the WordPress attack surface. Patchstack’s data shows 91% of vulnerabilities live in plugin code, with most exploited within hours of disclosure. Falling behind on plugin updates is the most common single reason WordPress sites get compromised – and tightening up your WordPress security practices starts here.<\/p>\n\n\n\n

If you want a daily alert rather than automatic updates, WP-CLI handles the check cleanly:<\/p>\n\n\n\n

0 4 * * * cd \/home\/USER\/public_html && wp plugin list –update=available | mail -s “Plugin updates available” you@yourdomain.com<\/p>\n\n\n\n

If you want fully automatic updates, swap list –update=available for update –all:<\/p>\n\n\n\n

Disclaimer<\/strong>: If you have already input your Cron Email in SPanel\/cPanel, there is no need of | mail-s in the command?<\/p>\n\n\n\n

0 4 * * * cd \/home\/USER\/public_html && wp plugin update –all <\/p>\n\n\n\n

If you run this through SPanel, use the Cron Job Manager\u2019s manual run option first. Manual-run output is captured after the command finishes, and scheduled execution may behave differently for unusual pipe-heavy commands.<\/p>\n\n\n\n


Here’s the thing – auto-updating plugins in production isn’t always the right call. A bad plugin update has taken down more sites than any hacker. Staging environments exist for a reason. The conservative pattern is alert-only in cron, then apply the update manually after testing.<\/p>\n\n\n\n

If WP-CLI isn’t available on your host, you can write a small PHP script that queries the WordPress updates API and emails the results – but that’s more code than a one-liner can handle.<\/p>\n\n\n\n

5. Monthly Database Optimization (1st of Each Month, 5 AM)<\/strong><\/h3>\n\n\n\n

The problem:<\/strong> as you write, edit, delete, and revise content, MySQL doesn’t always reclaim freed space efficiently. Over time, tables become fragmented, and query times creep up. WooCommerce and busy comment systems suffer the most – fixing this is one of the simpler wins in any WordPress performance optimization routine.<\/p>\n\n\n\n

Using WP-CLI:<\/p>\n\n\n\n

0 5 1 * * cd \/home\/USER\/public_html && wp db optimize <\/p>\n\n\n\n

Without WP-CLI, plain mysqlcheck does the equivalent:<\/p>\n\n\n\n

0 5 1 * * mysqlcheck –optimize -u DB_USER -pDB_PASS DB_NAME<\/p>\n\n\n\n

Why monthly:<\/strong> optimization briefly locks tables. Run it too often, and you’ll create short freezes that real users feel. Once a month, at 5 AM on the 1st, is the standard sweet spot.<\/p>\n\n\n\n

6. Daily SSL Expiration Check (Every Day, 6 AM)<\/strong><\/h3>\n\n\n\n

The problem:<\/strong> SSL certificates expire. Even auto-renewing certificates fail sometimes – a misconfigured renewal hook, a domain that didn’t validate, an Auto SSL provider having a bad day. When they expire silently, your visitors see a giant red browser warning before you do.<\/p>\n\n\n\n

A one-liner that emails you when the certificate has fewer than 14 days left:<\/p>\n\n\n\n

0 6 * * * echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>\/dev\/null | openssl x509 -noout -checkend 1209600 || echo “SSL expiring soon for yourdomain.com” <\/p>\n\n\n\n

The -checkend 1209600 flag returns a non-zero exit code if the certificate expires within 14 days. The || after it runs the alert email only when that check fails – silence when everything’s fine.<\/p>\n\n\n\n

Adjust the window to match your operational comfort: 30 days (-checkend 2592000) gives you more reaction time; 7 days (-checkend 604800) is quieter but doesn’t leave much room for a renewal gone sideways.<\/p>\n\n\n\n

Important<\/strong>: On ScalaHosting managed VPS plans, SPanel Website Monitoring<\/strong> can already check SSL expiration and alert you when a certificate is within 72 hours of expiry, so most SPanel users should enable that first. Use a cron-based SSL check only when you want an extra independent alert or when you are adapting the command for a non-SPanel environment.<\/p>\n\n\n\n

The Weekly Schedule at a Glance<\/strong><\/h2>\n\n\n\n

Here’s what these six jobs look like running together across a typical week:<\/p>\n\n\n\n

\"6<\/figure>\n\n\n\n

Quick scan<\/strong>: only one job (wp-cron) runs continuously. The other five fire once a day, once a week, or once a month – small, predictable bursts during low-traffic hours, all wrapped up by 6 AM.<\/p>\n\n\n\n

How ScalaHosting Handles WordPress Cron Differently<\/strong><\/h2>\n\n\n\n

The honest version of setting up cron jobs on most hosts: you paste the entry, save it, and wait until 3 AM to find out whether it worked. If it didn’t, you might never know – your job fails silently, the output gets sent to a Unix mailbox you’ve never logged into, and the work simply doesn’t happen.<\/p>\n\n\n\n

We do things differently at ScalaHosting.<\/p>\n\n\n\n

We built the Cron Job Manager<\/strong> in SPanel<\/a> to fix the parts of this workflow that frustrate everyone. A “run now” button executes any job immediately and captures the output in the panel, so you can verify a command works <\/strong>before<\/em><\/strong> trusting it to the schedule<\/strong>. The default email setting is silence – no inbox spam from a mailbox nobody checks – but you can flip on notifications with one field when you want them. And every cron job runs under your hosting account user, not root, so the same Linux permission boundary that protects your files protects your scheduled tasks as well.<\/p>\n\n\n\n

Some of these jobs are better handled natively on ScalaHosting managed VPS plans. SPanel account-level backups protect WordPress files and databases on the configured backup schedule, while WordPress Manager<\/a> handles WordPress core, plugin, and theme updates through the panel. For risky changes, WordPress Manager staging lets you test updates before touching production. That means cron is useful for custom workflows, but it should not replace the safer built-in tools where SPanel already covers the job.<\/p>\n\n\n\n

The other four (real wp-cron, weekly cleanup, monthly database optimization, SSL expiration check) live in the Cron Job Manager, where you can paste and test them with one click.<\/p>\n\n\n\n

Security-wise, SShield<\/a> runs continuously in the background and blocks 99.998% of known web attack patterns before they reach your site. It doesn’t replace the maintenance cron jobs above, but it absorbs the brute-force noise so the alerts you do receive – from your plugin update check, your SSL monitor – aren’t drowned out.<\/p>\n\n\n\n

All of this runs across managed VPS infrastructure that currently hosts more than 700,000 websites across 120+ countries. <\/p>\n\n\n\n

Task<\/strong><\/th>Use cron?<\/strong><\/th>Better SPanel option?<\/strong><\/th>Notes<\/strong><\/th><\/tr><\/thead>
Replace wp-cron<\/td>Yes<\/td>Cron Job Manager<\/td>Good fit; test with Run Now.<\/td><\/tr>
Database backup<\/td>Sometimes<\/td>SPanel account backups<\/td>Use cron dump only as an extra export layer.<\/td><\/tr>
Plugin update check<\/td>Sometimes<\/td>WordPress Manager updates\/staging<\/td>Alert-only is safer than auto-update in production.<\/td><\/tr>
Plugin auto-update<\/td>Be careful<\/td>WordPress Manager auto-updates\/staging<\/td>Test on staging first.<\/td><\/tr>
DB optimization<\/td>Sometimes<\/td>Manual\/admin review for busy stores<\/td>Can lock tables; avoid overuse.<\/td><\/tr>
SSL expiration check<\/td>Usually no on SPanel<\/td>Website Monitoring \/ AutoSSL<\/td>SPanel already alerts before expiry.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The Takeaway<\/strong><\/h2>\n\n\n\n

Six cron jobs. None of them complicated. All of them quietly prevent the kind of Monday-morning emergencies that get blamed on WordPress when the real culprit was a missing background task.<\/p>\n\n\n\n

Set them up once. Make sure they actually run. Then forget about them – which is the whole point of a scheduler in the first place.<\/p>\n\n\n\n

If you’re running WordPress on a host where setting up and testing cron jobs is more friction than it should be, take a look at our managed VPS plans – the Cron Job Manager and WordPress Manager are included with every one.<\/p>\n\n\n

\r\n \"shortcode-logo\"\r\n
\r\n \"shortcode-bg\"\r\n <\/div>\r\n
\r\n
\r\n
Supercharge Your Business with an All-inclusive Fully Managed Cloud<\/div>\r\n
\r\n
\r\n
Free, Effortless & No-Downtime Migration<\/b><\/div>\r\n
Anytime Unconditional Money-back Guarantee<\/b><\/div>\r\n
Full Scalability & 24\/7 Expert Cloud Support<\/b><\/div>\r\n <\/div>\r\n <\/div>\r\n
\r\n
\r\n Start Now<\/a>\r\n <\/div>\r\n
\r\n