Before updating any plugin, see exactly what it touches — shared hooks, custom database tables, cron jobs, REST routes, and historical error data — with a 0–100 Blast Radius Score and a Low / Moderate / High / Critical risk rating.
Most plugin updates are safe. Some are not. The difference is usually invisible until the site breaks. Pre-Update Impact Analysis makes the risk visible before you click Update. For every pending plugin update, it scans the plugin's codebase to determine how deeply it is woven into your site — how many hooks it shares with other active plugins (the highest-weighted risk factor, because these are real conflict points), which custom database tables it owns, how many scheduled jobs it runs, how many REST endpoints it registers, how large its asset bundle is, and whether it has a history of PHP errors on this site. These factors combine into a single 0–100 Blast Radius Score with a plain-English risk summary, cached for 30 minutes so repeated views are instant.
A single numeric score computed from six weighted factors — shared hooks carry the highest weight (max 35 points) because they represent real conflict points with other active plugins. Custom DB tables, cron jobs, REST routes, asset size, and error history make up the rest. The score maps to four risk tiers: Low (0–24), Moderate (25–49), High (50–74), and Critical (75–100). A plain-English summary explains exactly what contributes to the score.
The analysis scans the plugin's PHP files for every WordPress action and filter it registers. Each hook is then compared against the hooks registered by all other active plugins via the live $wp_filter. Shared hooks — hooks where both the plugin being updated and at least one other active plugin register callbacks — are the primary conflict risk. The report lists each shared hook, its priority, and the other plugins that use it.
The module identifies every custom database table the plugin owns, along with approximate row counts. Plugins with large custom tables carry a higher update risk because major version updates often include database schema migrations — which can fail silently or corrupt data when run on production sites with large datasets. Each table is named explicitly so you know what's at stake before updating.
Scheduled cron jobs are extracted from the plugin's source code by scanning for wp_schedule_event and wp_schedule_single_event calls. REST API routes are identified by scanning for register_rest_route calls. Plugins with many scheduled jobs or REST endpoints have a broader operational footprint — changes to hook timing or route signatures in an update can break integrations with other plugins or external services.
The module checks your PHP error log for errors that originated inside the plugin's folder. A plugin that has already produced PHP errors on this specific site is inherently higher risk for future updates — the errors reveal existing fragility. The historical error contribution is factored into the Blast Radius Score at a lower weight (max 5 points) so it nudges the score without dominating it.
Scanning a plugin's PHP files for hooks, cron registrations, and REST routes takes a moment on the first load. The analysis result is cached in a 30-minute transient so that repeated visits to the Pre-Update page are instant. The cache is keyed to the plugin file and version, so it automatically invalidates if a new version is detected.
Shared hooks are where plugin conflicts actually happen. When two plugins register callbacks on the same hook at the same priority, their execution order is non-deterministic — and a change in one plugin's callback behavior can silently break the other's. The more hooks a plugin shares with other active plugins, the more likely an update to its callback logic is to cause unexpected behavior elsewhere. DB tables and cron jobs matter too, but hook conflicts are the most common cause of post-update breakage.
Yes — the module scans the plugin's PHP files for hook registration calls (add_action, add_filter), cron scheduling calls (wp_schedule_event, wp_schedule_single_event), and REST route registration (register_rest_route). It also compares registered hooks against the live $wp_filter registry to identify which are shared with currently-active plugins. The scan is read-only and does not execute any plugin code.
Not necessarily — it means the update carries higher risk and warrants more caution. A Critical score for WooCommerce, for example, is expected — it has a massive hook footprint and custom tables. The appropriate response is to test the update on a staging environment before applying it to production, not to skip it entirely. The score is a risk indicator, not a recommendation to avoid updating.
A changelog tells you what the developer changed in their code. Pre-Update Impact Analysis tells you how that plugin is currently woven into your specific site — which hooks it shares with your other active plugins, which tables it owns, and whether it has a history of errors on this installation. Two sites can have the same plugin installed and get very different risk scores, because the risk depends on what else is active alongside it.
No — Pre-Update Impact Analysis is available in WP Health Inspector Pro only. The free Lite version includes the What Changed? module, which helps you trace what broke after an update. Pro adds the ability to assess risk before the update happens.
Pre-Update Impact Analysis is available in WP Health Inspector Pro — alongside all twenty diagnostic modules.
Pre-Update Impact Analysis plus all nine Pro-exclusive modules and all ten free modules — one plugin, complete visibility.
Pairs with What Changed? for a complete update workflow: assess risk before, trace causes after.
The free Lite version includes What Changed? — start tracing what broke after your last update, at no cost.
Upgrade to Pro when you're ready to assess risk before updates happen.
