Count of plugin / theme updates in last 24h. When this >0 AND order error rate spikes, almost always indicates plugin-side regression. Pair with failed-orders-24h.
At a glance
A rolling count of how many plugins and themes were updated on your store in the last 24 hours. On WooCommerce, the single most common cause of a sudden checkout break or order-error spike is a plugin or theme update, often an auto-update applied overnight without anyone noticing. This card is the “what changed?” answer you reach for the moment something breaks. On its own a non-zero count is routine; the alert fires only when an update coincides with an order-error spike, because that pairing almost always means a plugin-side regression.
Calculation
Calculated automatically from your WooCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A self-hosted WooCommerce store on WC 9.0 with WP auto-updates enabled. At 03:00 UTC on 11 Jun 26, WordPress applied three overnight plugin updates. The merchant opens Nerve Centre at 09:00.
Four things to notice:
- The count alone is not the alert. Three overnight updates is routine for an auto-updating store. The alert fires because the count is
>0AND Failed Orders (Last 24h) spiked in the same window. That pairing is the regression signal, not the update count by itself. - The timeline points straight at the cause. Errors began at 06:00, three hours after the 03:00 update batch. The Stripe Gateway update is the obvious first suspect because it sits directly in the checkout path. The merchant’s first move is to roll that plugin back to its previous version on staging and retest.
- Auto-updates landed with no human in the loop. Nobody chose to update at 03:00, WP’s scheduled auto-update did. This is exactly why the card exists: on a self-hosted store with auto-updates on, the thing that broke checkout may have changed while everyone slept.
- The window is rolling 24h, so the count self-clears. By 11 Jun 26 at 03:01 the three updates fall outside the trailing 24h and the count returns to 0, even if the regression is unresolved. Capture the timeline while the alert is live, and use Plugin Compatibility Audit to see whether the updated plugin is now flagged against your core version.
Sibling cards merchants should reference together
Reconciling against WooCommerce
Where to look in WordPress / WooCommerce Admin: WP Admin → Plugins shows each plugin’s current version, and WP Admin → Dashboard → Updates shows what was recently updated and what is pending. For an audit trail of who updated what and when, an activity-log plugin (WP Activity Log, Simple History) is the most reliable first-party-style record. Other WP Admin views that touch the same data:- WP Admin → WooCommerce → Status → System Status: lists active plugins and their versions, the snapshot this card diffs between syncs.
- WP Admin → WooCommerce → Status → Logs: gateway and checkout plugins log errors here, which is where a post-update regression often leaves its first trace.
- Your managed host’s update log: managed-Woo hosts (Woo.com Cloud, WP Engine, Pressable, Kinsta) keep their own record of host-applied updates, which also count toward this card.
Known limitations / merchant FAQs
Is a non-zero count a problem on its own? No. Updates are healthy and routine, especially on stores with auto-updates enabled. The card becomes a warning only when the count is>0 and order errors spike in the same window, because that combination almost always means a plugin or theme update introduced a regression. A non-zero count with stable orders is just normal maintenance.
An update broke my checkout, what is the fastest fix?
Identify the most likely suspect (anything in the checkout or gateway path, such as the Stripe Gateway or a tax plugin), roll it back to its previous version on a staging copy, and retest checkout. If staging confirms the fix, apply the rollback to production and report the regression to the plugin author. Pair this card with Failed Orders (Last 24h) and Checkout Error Rate (24h) to confirm the timeline.
The count went back to zero but my problem is not fixed, why?
The window is a rolling 24 hours, so updates fall out of the count once they are more than a day old, regardless of whether the issue they caused is resolved. The count clearing does not mean the regression cleared. Capture the timeline while the alert is live, then track resolution through the order-error cards.
Does this count activations or deactivations?
No. It counts version changes to installed plugins and themes, not status changes. Activating or deactivating a plugin does not change its version, so it does not register here. If you want the active-set view, see Active Plugin Count.
Why did an update appear that I did not apply?
Either WordPress applied a scheduled auto-update, or your managed host applied a patch on your behalf. Both change the installed version and both count here. This is one of the card’s most useful behaviours: it surfaces silent changes that broke something while no human was watching.
How quickly does an update show up in the card?
As fast as the next successful sync, typically within an hour on a self-hosted store. If the host was slow or unreachable when the update landed, detection waits for the next clean poll. For a store with frequent auto-updates, expect near-continuous visibility of recent version changes.