At five sites you can keep everything in your head. At fifteen you need a spreadsheet. At fifty the spreadsheet is lying to you and you do not know which rows.
The difference between an agency that scales past this point and one that stalls is rarely talent. It is whether the work of running sites grows with the number of sites, or with the number of exceptions.
The cost does not grow linearly
The usual framing is that each site adds a fixed increment of work. That understates it, because three costs grow at different rates and one of them compounds.
Update volume grows linearly. Fifty sites with twenty plugins each is a thousand installed components. At a plugin release cadence of roughly monthly, that is a continuous stream of updates that never ends and never gets smaller.
Incident surface grows linearly. More sites, more outages, more 3am pages, more clients emailing about something you have not seen yet.
Configuration drift grows worse than linearly. This is the one that actually breaks agencies. Every site accumulates its own exceptions: the client who insisted on that plugin, the one where a fix was applied manually and never documented, the one restored from an old backup that quietly reverted its hardening. The cost is not maintaining fifty sites. It is maintaining fifty different sites, and the number of ways they can differ grows faster than the count.
Automation addresses the first two. Only standardisation addresses the third, which is why "we will fix it with a tool" fails on its own.
What centralisation changes
A control plane connected to every site turns a set of individual questions into one query. That sounds like convenience and is actually a change in what is possible.
"Is this site backed up" is a question you can ask fifty times. "Which sites are not backed up" is a question you can only ask if something holds all fifty. The first scales with your patience; the second does not scale at all, which is the point.
The same applies to "which sites are running a vulnerable version of this plugin", asked the morning a disclosure lands. Answering that by logging into fifty dashboards takes a day. Answering it from a fleet inventory takes a moment, and the difference decides whether you patch before or after the exploit traffic arrives.
Updating a fleet without breaking it
The instinct once bulk updates are available is to apply everything everywhere. That works until the day it does not, and the day it does not, it fails across your entire portfolio simultaneously.
A sequence that holds up:
- Snapshot before every update. Not nightly, immediately before. A broken update then becomes a rollback rather than an incident, and this single practice removes most of the risk of the rest.
- Stage the risky ones. Major version bumps, core updates, anything touching checkout, membership, or forms. Not everything needs staging, and pretending it does means nobody does it.
- Batch by risk, not alphabetically. Update low-stakes sites first, confirm they are healthy, then move up. Your own site and internal projects make excellent canaries.
- Wait between batches. A plugin update that breaks something rarely breaks it instantly. A short soak after each batch catches problems while the blast radius is small.
- Watch afterwards, and watch for the right thing. A fatal error is obvious. A contact form that silently stopped sending is not, and it is the failure that costs a client relationship. Uptime checks that look for expected content rather than a 200 status catch the second kind.
WPMgr automates the snapshot and the post-update monitoring. Batching is a configuration choice per site or per tag group. Staging still needs a staging environment, which not every client site will have, and it is worth being honest with yourself about which ones do.
Backups fail silently, which is the whole problem
The dangerous backup failure is not the one that errors. It is the one that reports success.
A job that ran but timed out partway. A destination whose credentials expired three weeks ago. A database dump that has been producing a valid, empty file since a schema change. Each of these produces a green tick and a backup you cannot restore from, and you find out at the worst possible moment.
At fifty sites nobody is checking this by hand, which means the check has to be structural. What you want surfaced is not "backups are on" but the specific anomalies: sites with no successful backup in the last 24 hours, sites where the backup size dropped sharply against its own history, sites whose last success is older than their schedule implies.
Size is the underrated signal. A backup that suddenly shrinks by 60 percent is almost always a partial capture, and it is invisible to any check that only looks at success or failure. WPMgr's backup health view reports last timestamp, status, and size per site, and flags staleness and size anomalies specifically, because those are the two failures that pass a naive check.
Tags are how a fleet stays navigable
At fifty sites you stop working with sites and start working with groups. Tagging is what makes bulk operations safe, because it lets you say "the low-risk brochure sites" rather than "all of them".
Groupings that earn their keep in practice: by client, so reporting and offboarding are one filter away; by risk, separating commerce and membership from brochure sites; by platform version, so you can find every site still on an old PHP release when your host announces a deprecation; and by hosting provider, because that is the unit that fails together during an outage.
That last one is worth setting up before you need it. When a host has an incident, the useful question is "which of my sites are on that provider", and it is very hard to answer retroactively at speed.
Alerting has to survive being ignored
Monitoring fifty sites generates enough events that the design question stops being "will we be told" and becomes "will anyone still be reading".
Alert fatigue is not a personality failing. It is the predictable result of a channel where most messages need no action. Once a channel is mostly noise, people stop reading it, and the one alert that mattered arrives into a room nobody is in. The failure is silent and you only discover it during an incident.
Three rules keep it usable.
Alert on confirmed conditions, not single observations. One failed check from one location is usually a network blip. Requiring two or three consecutive failures, ideally from different vantage points, removes most false positives at the cost of a minute of detection time. That is nearly always the right trade.
Separate what wakes someone from what waits. A site being down is an interrupt. A TLS certificate expiring in three weeks is a task. Sending both to the same place guarantees the second trains people to ignore the first.
Alert on recovery too. An incident channel that only reports failures leaves everyone unsure whether the thing resolved itself, which produces exactly the manual dashboard-checking that centralisation was meant to remove.
The related discipline is expiry. TLS certificates, domain renewals, and payment methods on hosting accounts all fail on a date you could have known months ahead. These are not monitoring problems, they are calendar problems, and they take out more client sites in practice than intrusions do.
Access is a fleet-level risk
The structural weakness in most agency setups is not any individual site. It is that access to all of them is concentrated and casually managed.
The pattern to avoid is a shared admin password reused across a client portfolio. It converts one exposure into fifty, and it is common because it is convenient in exactly the way that makes it dangerous.
What to do instead is unglamorous: one account per person per site rather than a shared login, credentials in a password manager rather than a spreadsheet or a pinned message, two-factor on the control plane and the hosting accounts as well as the sites, and an offboarding step that actually runs. A departed contractor with live administrator accounts across a portfolio is a common and entirely avoidable exposure.
Client offboarding deserves the same treatment. When an engagement ends, remove your agent, your accounts, and your monitoring, and confirm the client has their backups. Leaving access in place after the relationship ends is a liability with no upside.
Standardise onboarding, then never deviate
Configuration drift starts on day one. A repeatable onboarding checklist is the cheapest control available, and the one most often skipped because the first few sites did not need it.
- Install and activate the agent on the site.
- Connect it to the control plane.
- Run initial diagnostics: core, PHP, and plugin versions, existing uptime, current backup state.
- Configure the backup destination and schedule.
- Apply the security baseline: login hardening, attempt limits, two-factor policy.
- Tag the site: client, risk level, host.
- Confirm the first backup actually completed, and check its size looks plausible.
- Set up uptime monitoring and the alert threshold.
- Schedule the first client report.
Step 7 is the one that gets skipped, and it is the one that determines whether the other eight mattered. A backup configured is not a backup taken.
WPMgr handles steps 3 through 9 from one interface once the site is connected.
Reporting is a byproduct, not a task
Clients ask what you have been doing. Reconstructing an answer from memory is slow, unreliable, and quietly undersells the work, because you forget most of it.
If every action is recorded as it happens, the report is a query rather than an exercise. WPMgr's audit log records each operation, what changed, who did it, and when, and white-label reports generate from that log on a schedule.
The strategic point is that this is the artefact that justifies a retainer. Maintenance done well is invisible by construction: nothing breaks, so there is nothing to see. A report is what converts invisible work into evidence, which is why maintenance reports belong in the operational system rather than bolted on at renewal time.
For the agency toolset, see the for agencies solution guide and the white-label reports feature page.