WordPress added per-plugin auto-update toggles in version 5.5, giving operators granular control over what updates while they sleep and what waits for manual approval. The feature sits quietly in the plugin list, easy to miss—but using it correctly can prevent broken checkout pages, missing forms, and late-night rollback sessions.
Most solo operators treat auto-updates as binary: all on or all off. That leaves money on the table. The right approach is selective, based on each plugin’s role and the vendor’s track record.
How the feature works
Each plugin row in your WordPress dashboard includes an “Enable auto-updates” link. Toggle it on, and WordPress checks twice daily for new versions and installs them without intervention. The core system sends an email notification after each auto-update completes, listing what changed and linking to the changelog (checked November 2026, WordPress.org plugin documentation).
Auto-updates run during the standard WordPress cron cycle, typically in low-traffic hours if your server respects the schedule. If an update fails mid-install, WordPress attempts to roll back to the previous version and logs the error. It doesn’t always succeed—especially if the failure involves database schema changes.
The feature works independently of theme auto-updates and core auto-updates. You can run all three, none, or any combination.
Which plugins to auto-update
Enable auto-updates for plugins that meet all three criteria: low site-integration complexity, frequent security patches, and a vendor with a clean deployment history.
Security and anti-spam plugins top the list. Akismet, Wordfence, and similar tools release patches within hours of discovering new attack vectors. Waiting even a day to manually update exposes your comment forms and login pages. These plugins rarely touch your theme or content rendering, so breakage risk stays low.
Performance and caching plugins are the opposite. A caching plugin update can silently break CSS delivery, JavaScript execution, or CDN purging. If you run WP Rocket, W3 Total Cache, or similar, keep auto-updates off and test each release on a staging site first. The performance gain from a new version rarely justifies the risk of a broken front-end during a product launch.
Page builders and form plugins sit in the middle. Elementor, WPForms, and Gravity Forms push updates often, and most are stable—but a bad release can take your lead-capture forms offline or scramble post layouts. If your business depends on a single landing page or checkout flow, disable auto-updates and schedule manual testing weekly. If you run dozens of pages and can tolerate occasional layout shifts, auto-updates save time.
SEO and analytics plugins—Yoast, Rank Math, MonsterInsights—are safe to auto-update unless you’ve customised their output with filters or hooks. They touch metadata and tracking scripts, not front-end rendering, so breakage is rare. The exception: if you’ve hard-coded schema markup or custom Open Graph tags that conflict with plugin defaults, test updates manually.
One non-obvious trick: auto-update only after vendor testing
Many plugin vendors release updates in waves. They push to a small percentage of installs first, monitor error reports for 24–48 hours, then roll out globally. If you enable auto-updates, you’re in the first wave by default.
To stay in the second wave—where critical bugs have already been patched—leave auto-updates off and manually update three days after a release appears in your dashboard. Check the plugin’s WordPress.org support forum or changelog for version increments like 3.2.1 following 3.2.0. If you see a point-release within 72 hours, the initial version had issues.
For mission-critical plugins, subscribe to the vendor’s release notes via RSS or email. Most publish a changelog feed at pluginname.com/changelog or link it from their WordPress.org page. Skim each update summary before toggling auto-updates back on.
When auto-updates cause problems
Two failure modes happen often enough to plan for: email notification fatigue and silent cron failures.
If you run fifteen plugins with auto-updates enabled, you’ll receive fifteen separate emails each time WordPress checks for updates—sometimes multiple per day if vendors release patches quickly. The volume trains you to ignore the messages, so you miss the one notification warning that a payment plugin failed to update and left your checkout broken. Consolidate auto-update notifications by filtering them into a dedicated email folder and reviewing it once weekly, or disable the emails entirely and check the plugin list manually.
Silent cron failures happen when your hosting provider disables WordPress’s built-in cron and replaces it with a server-level cron job that doesn’t fire reliably. Auto-updates queue but never execute. Check your wp-config.php file for the line define('DISABLE_WP_CRON', true);—if present, confirm your host has configured a replacement cron job at wp-cron.php and that it runs at least twice daily (checked November 2026, WordPress developer cron documentation).
If you’re running WordPress on BigScoots or a similar managed host, ask support to confirm cron job frequency before relying on auto-updates for time-sensitive security patches.
One last thing: We publish a new operator-focused guide like this one every day. Subscribe to One Two Three Send to get tomorrow’s in your inbox.