Seven ways an update breaks a site: what WordPress and Update Watch catch

Published November 5, 2026

Short answer. We broke a test site seven different ways with a plugin update. WordPress’s own auto-update rollback caught 1 of the 7. With Update Watch’s suggested pages, WordPress and Update Watch together caught 2. With three pages and one check text chosen for the site, they caught 4, and Update Watch’s alert arrived about a minute after the update. Three kinds of breakage were missed by both.

The test

A fictional plugin, Demo Slider, goes from 1.0.0 to 1.1.0 through the real WordPress auto-updater on WordPress 7.1.4. Each 1.1.0 breaks the site in one way. After each run we record what WordPress did, what Update Watch logged and emailed, and what a visitor would actually see.

“Suggested pages” are what Update Watch proposes when you first open it: the home page with the site title as the text to find, plus the latest post (and the shop and checkout on a WooCommerce site). “3 pages + check text” is what someone who knows the site would set: the home page with the text that must be there (here, the slider), a post and the shop page.

We also updated by hand with WP-CLI, where WordPress has no rollback at all. A fatal error on every page and a fatal error on posts both produced an Update Watch alert at once.

What this means

• WordPress’s rollback is narrow. It tests the home page for a fatal error during automatic updates. Everything else gets through.
• The setup matters more than the tool. Out of the box, with only the home page, Update Watch added nothing in this test. The pages you add, and a check text that names the content that matters, decide what gets caught.
• No false alarms. The healthy update never produced an alert.
• Not a security scanner. An update that adds a hidden endpoint, or slows the site down, passes. Neither tool looks at the dashboard as a logged-in user.

What we fixed after the first run

The first run found three problems in Update Watch, and all three were fixed before this page:

• After WordPress rolled an update back, Update Watch still sent a “check failed” alert. It now logs the restore and stays quiet.
• After a manual update that broke every page, no check ran, because WordPress’s scheduler ran inside the broken site. Update Watch now checks at the end of the update itself.
• The default setup checked only the home page. The settings now suggest pages for your site.

Limits of the lab

There was no visitor traffic, one plugin and one update at a time, and no page cache. The dashboard-update path on PHP-FPM or LiteSpeed servers is covered by automated tests but was not measured here. The benchmark scripts and raw results will be published with the plugin source code.

Questions

Does WordPress roll back a plugin update that breaks the site?

Only an automatic update, and only when the update causes a fatal error on the home page right away. Since WordPress 6.6 it then restores the previous version and emails the site admin. In our lab it missed errors on single posts or on one page, content that silently disappeared, and errors only in the dashboard.

How fast does Update Watch alert after a broken update?

In our lab, about 66 seconds after an automatic update, and at once after an update made with WP-CLI. It checks the pages you choose and the PHP error log.

Can Update Watch tell if a plugin update added a backdoor?

No. Update Watch checks that your pages still load and show what they should. A malicious update that keeps the site working looks like any other update to it.

The plugins in this case

Update Watch: Know within minutes when an update breaks your site.

All case studies