How to Track WordPress Plugin Updates Across Every Site You Manage

Plugins are where most WordPress trouble starts. A single update can white-screen a site, break a checkout, or open a hole that gets the whole thing defaced. If you manage more than a handful of sites, the hard part is not applying updates. It’s knowing what changed, when, and on which site after something goes wrong.

This guide covers what plugin tracking should actually record, why the tools built into WordPress can’t give you a history, and how to keep an accurate record across every site without living in spreadsheets.

Why plugin updates are the thing to watch

The two most common ways a WordPress site fails both run through plugins.

The first is breakage. A plugin update ships a change that conflicts with your theme, another plugin, or an older PHP version. The site was fine at 2pm and broken at 2:05, and the only thing that happened in between was an update you may not have triggered yourself.

The second is security. Outdated plugins are the single largest source of WordPress compromises. Attackers scan for known-vulnerable versions and hit them at scale. An abandoned plugin sitting two versions behind is a standing invitation, and you often can’t see which sites are exposed until you check each one by hand.

Both problems share a root cause: you don’t have a running record of plugin state across your sites. Tracking gives you that record. It won’t apply the update for you, but it tells you exactly what happened so you can react in minutes instead of hours.

What “tracking” should actually capture

“I track my plugins” usually means someone glances at the Plugins screen now and then. That’s not tracking, that’s a snapshot. Real tracking is a timeline of every event that changes plugin state:

• Installs — a new plugin added to the site, with the name, version, and who added it.
• Activations — an installed plugin switched on, which is when its code actually starts running.
• Updates — the important one. You want the version before and after, so a jump from 3.1.4 to 3.2.0 is recorded as exactly that, not just “updated.”
• Deactivations — a plugin switched off, which often precedes a removal or signals someone was troubleshooting.
• Deletions — a plugin removed entirely, with the last version that was present.
• Auto-updates — changes WordPress applied on its own overnight, which are the ones nobody remembers making.

The version-before-and-after detail is what makes an update log useful for debugging. “Updated WooCommerce” tells you nothing. “WooCommerce 8.6.1 → 8.7.0 at 03:14, auto-update” tells you what to roll back to and where to look. This is the level of detail plugin monitoring is built to record.

The WordPress plugins screen has no memory

Open Plugins in wp-admin and you see the current state: what’s installed, what’s active, what has an update waiting. That’s genuinely all it does. It has no history.

There is no answer inside core WordPress to “what changed on this site yesterday?” The screen can’t tell you a plugin was updated at 3am by an auto-update, that someone deactivated a caching plugin last Tuesday, or that a plugin you don’t recognize was installed a week ago. Once a change happens, the previous state is gone. The screen shows now, and only now.

This is fine for a single site you check daily. It falls apart the moment you’re responsible for ten, fifty, or a hundred sites, because “now” on each of them is a moving target you can’t see all at once.

Why the manual approaches don’t scale

Most people try to close this gap by hand before they look for a tool.

The spreadsheet. You list each site, each plugin, and the current version, and you promise to update the sheet whenever something changes. It works for about two weeks. The moment auto-updates run overnight, or a client installs something, or you make a quick fix and forget to log it, the sheet is wrong. And a maintenance record you can’t trust is worse than none, because it makes you confident about the wrong thing.

Checking each site. You log into every dashboard on a schedule and eyeball the Plugins screen. This scales linearly with the number of sites, which is to say it doesn’t scale. Twenty sites at a few minutes each is an hour of clicking that produces a snapshot you’ll have to repeat tomorrow, and it still gives you no history of what happened between visits.

Reading emails. WordPress sends an email when an auto-update runs. Across a fleet, those emails become noise you filter out, and they only cover auto-updates, not the manual changes people make.

The common failure is that all three depend on a human remembering to record something at the exact moment it happens. Tracking has to be automatic, or it isn’t reliable.

Tracking automatically with a connector and a dashboard

The reliable approach is to have the sites report changes themselves, as they happen.

VigilDeck works with a free connector plugin installed on each WordPress site. It hooks into the events WordPress already fires for plugin installs, activations, updates, deactivations, and deletions, and writes them to a local activity log on that site. Nothing depends on anyone remembering to make a note. The plugin records the event the instant it occurs, including the version before and after an update.

The free tier keeps that log locally with a 7-day history across up to 3 sites, which is enough to see recent changes on a small setup. To watch a fleet from one place, the paid plan streams each event off-site as an HMAC-signed message to a central dashboard. Signing matters here: it means the record on the dashboard is tamper-evident, so a compromised site can’t quietly rewrite its own history to hide what an attacker changed.

On the multi-site dashboard you get one timeline across every connected site. You can see that three sites got the same plugin update overnight, that one site had a plugin installed you didn’t authorize, or that a deactivation lined up exactly with the moment a client reported a problem. It’s the history the native Plugins screen was never going to give you, aggregated across the whole fleet.

Turning pending updates into a smaller attack surface

Tracking isn’t only a record of the past. The same connector reports which updates are pending on each site, and the dashboard rolls those up into one view.

Instead of logging into each site to find out what’s behind, you see every outstanding plugin update across the fleet in one list. That’s a direct read on your attack surface. The plugins sitting on old versions are the ones attackers scan for, and a pending-updates rollup shows you exactly which sites carry that risk right now.

That view lets you work by priority rather than by habit. A security release on a plugin that’s live on forty of your sites goes to the top. A minor update on a plugin you don’t even have active can wait. VigilDeck surfaces the same pending-update signal for WordPress core through core update monitoring, so plugins and core sit in one picture rather than two separate checks.

Root-causing a broken site fast

Here’s where an update history earns its keep. A client calls: the site was working this morning, now the homepage is blank.

Without a record, you’re guessing. You check for obvious errors, poke at recent changes you might remember, and hope. With a plugin timeline, you open the site’s activity in the dashboard and read what actually happened. If an auto-update ran a page-builder plugin from 4.9.2 to 5.0.0 at 03:00 and the site broke sometime after, you have your suspect and your rollback target in under a minute.

The version-before-and-after detail is what makes this fast. You don’t just know something updated. You know precisely which version was running when the site was healthy, so you can roll back to a known-good state instead of trial and error. That difference is often an afternoon of debugging versus a two-minute fix.

FAQ

Does VigilDeck update my plugins for me?

No. VigilDeck is a monitoring platform, not a management one. It records what changed and shows you what’s pending, but it doesn’t apply updates or make changes to your sites. You keep full control over when and how updates happen.

Will the connector plugin slow down my sites?

The connector hooks into events WordPress already fires and writes a small log entry when something changes. It isn’t running on every page load or adding front-end weight, so the overhead is negligible.

What happens to my history on the free plan?

The free tier logs locally on each site with a 7-day rolling history across up to 3 sites. Older events age out. If you need longer retention and one dashboard across more sites, the paid plans keep the full off-site history. You can compare tiers on the pricing page.

Can I track auto-updates I didn’t trigger?

Yes, and those are often the most useful entries. The connector records auto-updates the same way it records manual ones, with the version before and after, so overnight changes nobody remembers are still in the timeline.

Keep a record you can trust

The native Plugins screen shows you the present. Managing sites well means being able to answer questions about the past, quickly, across all of them at once. A connector that logs every plugin change and a dashboard that aggregates it is the difference between reacting to breakage and understanding it.

See how plugin monitoring records every install, update, and removal across your fleet, or check the pricing to start free on up to 3 sites.