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.
| What it counts | The number of distinct plugin and theme updates applied in the trailing 24 hours, whether triggered manually, by scheduled WP auto-updates, or by a managed-host update routine. |
| REST API endpoint | WordPress does not expose update history through the WooCommerce wc/v3 REST namespace. Updates are detected by comparing each plugin and theme version between syncs, the same version data the WP core update_plugins / update_themes transients and the WooCommerce Status System Report expose. A version change within the last 24h counts as an update. |
| What “update” means here | Any change to an installed plugin or theme version: a normal version bump, an auto-update, or a managed-host-applied patch. Activations and deactivations are not counted; this card tracks version changes, not status changes. |
| Why it matters | A plugin update can change the checkout flow, a gateway integration, tax calculation, or the orders table interaction. When an update lands and order errors climb in the same window, the update is the prime suspect. This card gives you the timeline to confirm or rule it out fast. |
| Self-hosted vs managed-Woo | Self-hosted stores often have WP auto-updates enabled, so updates can land overnight with no human in the loop, making this card especially valuable. Managed-Woo hosts (Woo.com Cloud, WP Engine, Pressable, Kinsta) frequently apply their own staged updates and patches, which also show up here. WordPress.com Business and Commerce plans auto-manage core and many plugins. |
| Time window | 24H (rolling trailing 24 hours) |
| Alert trigger | >0 AND error_rate_spike, driven by sentiment_key: wc_recent_plugin_updates_24h |
| Roles | owner, engineering |
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.| Time (UTC) | Event | Plugin Updates (Last 24h) | Failed Orders (Last 24h) |
|---|---|---|---|
| 10 Jun 26, 09:00 | Baseline, no recent updates | 0 | 2 (normal) |
| 11 Jun 26, 03:00 | Auto-update: Stripe Gateway, a tax plugin, a page-builder | 3 | 2 |
| 11 Jun 26, 06:00 | Checkout errors begin climbing | 3 | 14 |
| 11 Jun 26, 09:00 | Merchant opens Nerve Centre | 3 | 21 |
| Reading at 09:00 | 3 | 21 (spiking) |
- 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
| Card | Why pair it with Plugin Updates (Last 24h) |
|---|---|
| WC Failed Orders (Last 24h) | The other half of the alert condition. A non-zero update count plus a failed-order spike in the same window is the textbook plugin-regression signal. |
| WC Checkout Error Rate (24h) | Pinpoints whether the regression hit the checkout flow specifically, the highest-impact place a plugin update can break. |
| WC Plugin Compatibility Audit | Shows whether an updated plugin is now flagged as incompatible with your live WC / WP core version. |
| WC Plugins Out of Date | The inverse view: plugins that have not been updated. Useful for planning controlled updates rather than reacting to surprise ones. |
| WC WooCommerce Core Version | A WC core update is the highest-impact change of all and shows up here too. Confirm whether the version moved. |
| WC REST API Checkout Error Rate Spike | When a plugin update breaks the REST checkout path, this is where the spike surfaces. |
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.
| Reason | Direction of divergence |
|---|---|
| Time-zone. The 24h window is computed in UTC; WP Admin and activity-log plugins timestamp updates in the WP site timezone (Settings → General → Timezone). An update near the 24h boundary can fall inside our window but read as “yesterday” in WP Admin, or vice versa. | +/- updates right at the 24h boundary |
| Sync granularity. The card detects updates by diffing plugin versions between syncs (typically hourly). If a plugin was updated and then updated again within one sync interval, only the net version change is detected, so an intermediate version bump may not be counted separately. | Ours may count fewer discrete steps than an activity log |
| Self-hosted uptime / sync lag. If the host was unreachable when an update landed, the version change is detected at the next successful poll, so the update can appear in the card slightly later than it appeared in WP Admin. | Ours occasionally delayed; self-resolves at next clean sync |
| Auto-update visibility. WP scheduled auto-updates and managed-host patches do not always leave an obvious WP Admin notice, but they do change the version this card reads. The card may show an update the merchant did not consciously apply. | Ours surfaces silent auto-updates WP Admin downplays |
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.