WordPress plugin auto-updates are supposed to be set-and-forget. You toggle the setting, and your site stays patched without you logging into the dashboard every Tuesday. Except when the update runs halfway, stalls, and leaves your site in a state that doesn’t throw an error but quietly breaks functionality you won’t notice until a reader emails you three days later.
This isn’t a rare edge case. It happens because WordPress doesn’t use server cron—it uses WP-Cron, a pseudo-cron system that fires when someone visits your site. If your traffic is low, if your caching is aggressive, or if your hosting provider throttles background requests, WP-Cron jobs can skip, delay, or terminate mid-execution. Auto-updates are one of those jobs.
How WordPress plugin auto-updates actually run
When you enable auto-updates for a plugin, WordPress schedules a background task via WP-Cron. Twice daily, it checks for new versions. If an update is available, it triggers a multi-step process: download the new plugin zip, deactivate the old version, extract the new files, reactivate, and run any database migrations the plugin author included.
Each step depends on the previous one completing. If your server times out, if PHP hits its memory limit, or if WP-Cron doesn’t fire because no one visited your site in the last twelve hours, the process halts. WordPress doesn’t retry. It doesn’t log the failure in your admin dashboard. The plugin shows as the new version number, but the files might be a mix of old and new, or the database schema might still be two versions behind.
You’ll notice this when a form stops submitting, when an API integration returns a 500 error, or when your members area throws a white screen. The error logs—if your host surfaces them—will show a missing function or a table that doesn’t exist. The plugin version in your dashboard will say 2.8.4, but the actual code running will be 2.8.2 with one updated file.
What causes background job failures
Three common scenarios stall WP-Cron-based auto-updates. First: aggressive full-page caching. If every request is served from cache, WP-Cron never fires. Plugins like WP Rocket and hosts like BigScoots often bypass cache for logged-in users, but if you’re not logging in regularly and your traffic is mostly anonymous readers hitting cached pages, your cron jobs can go days without running.
Second: low memory limits. Shared hosting accounts often cap PHP memory at 128MB or 256MB. Plugin updates—especially for page builders or membership plugins—can exceed that during extraction and activation. The process dies silently, and WordPress moves on.
Third: server-level request timeouts. If your host enforces a 30-second execution limit and your plugin takes 35 seconds to update, the job terminates before completion. No retry, no notification.
How to fix this before it breaks your site
Disable WP-Cron and set up real server cron. Most hosts let you add a cron job in cPanel or via SSH. Add this to your wp-config.php file, above the “stop editing” line:
define('DISABLE_WP_CRON', true);
Then create a server cron job that runs every fifteen minutes:*/15 * * * * wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Replace wget with curl if your server doesn’t have wget installed. This forces WP-Cron to fire on schedule, regardless of traffic.
Second: increase your PHP memory limit. Add this to wp-config.php:define('WP_MEMORY_LIMIT', '512M');
If your host restricts this, ask support to raise it or switch to a host that gives you control. Most VPS and managed WordPress hosts let you set this yourself.
Third: monitor plugin update logs. Install a plugin like WP Crontrol to see which cron jobs are scheduled, when they last ran, and whether they completed. If you see wp_update_plugins or wp_maybe_auto_update stuck in the queue for days, your auto-updates aren’t running.
When to disable auto-updates entirely
If your site is mission-critical—handling payments, managing memberships, running a course platform—auto-updates introduce risk you don’t need. A plugin author can push a breaking change, and you won’t know until your checkout stops working. Manual updates with a staging site catch this. Auto-updates don’t.
For solo operators running content sites, auto-updates are convenient if your cron setup is solid. For teams running revenue-dependent infrastructure, the trade-off isn’t worth it. Test updates in staging, deploy during low-traffic hours, and keep auto-updates off for plugins that touch payments, user authentication, or data migrations.
If you do keep auto-updates enabled, audit your WP-Cron health quarterly. Check that jobs are firing, that memory limits are adequate, and that no plugin updates are stuck half-installed. That ten-minute audit prevents the three-hour debugging session when something silently breaks.
Want more infrastructure breakdowns? Reply with the hosting or plugin setup that’s giving you trouble—we’ll cover it in a future piece.