Uptime Monitoring for WordPress Agencies: 50+ Client Sites, One Dashboard

Bottom line: WordPress agencies need more than HTTP probes. A 200 from wp-admin can hide a broken login behind a cache or a security plugin lockout, and only a real browser session through wp-login.php catches it. Velprove Pro ($49/month) is sized as a 10-client plan: 100 monitors total (about 10 per client), up to 10 of them browser login monitors (1 per client), and 10 branded status pages, one per client on the client's own custom domain with no Velprove branding, all at 30-second HTTP intervals. One Pro plan = 10 fully covered, fully branded WordPress clients. Starter ($19/month) is the same shape at 3 clients. The free tier covers a multi-site pilot with no credit card required.

Your client's wp-admin returned a 200, but a real browser session through wp-login.php would have caught the failure. That gap is where agency monitoring lives or dies. If a CDN or page-cache layer strips the auth cookie, wp-admin can return a 200 from cache while the underlying request would actually redirect to wp-login.php. Your dashboard is green. Your client is locked out. Your account manager finds out from a Slack message that starts with "hey, quick question." The fix is not a faster ping. The fix is monitoring the same thing your client does: open a browser, log in, see the dashboard.

Why agency monitoring is a different problem from single-site monitoring

Single-site monitoring is a yes-or-no question. Agency monitoring is a routing problem, a reporting problem, and a margin problem stacked on top of each other. When you are running anywhere from 30 to 100+ sites for paying clients, the bottleneck is not the probe. The bottleneck is everything around it.

The three failure modes that ruin agency margins

First, false negatives: an HTTP probe says 200 while the real site is broken behind a cache or a plugin. Second, false positives: a flaky probe pages your on-call at 3am for a 30-second blip on a $30/month care-plan site. Third, attribution chaos: an alert fires and nobody on the team knows which client owns it, which account manager handles it, or whether the SLA promises a 15-minute or 4-hour response. Each one bleeds time. Time is the only thing an agency sells.

What "managing 50+ sites" actually means operationally

Operationally it means you need tags, naming conventions, tier-aware alerting, and reports that write themselves. It means a junior account manager should be able to look at the dashboard at 8am Monday and answer three questions in under a minute: did anything break this weekend, which client is affected, and is it already fixed. If your monitoring tool needs a senior engineer to interpret it, you do not have a monitoring tool. You have a second job.

Organizing monitors by client (tags, naming, groups)

The single biggest lever for agency-scale monitoring is naming. Get this right on day one and the rest of the system gets easier. Get it wrong and you will be renaming 200 monitors at month six.

A naming convention that survives client churn

Use client-slug:env:check-type. So acme-co:prod:wp-admin-login and acme-co:prod:homepage-uptime sit next to each other alphabetically. When Acme Co churns, you filter on acme-co: and archive the whole batch in one pass. When Acme Co adds a staging environment, acme-co:staging:homepage-uptime drops in cleanly. The colon separators are not arbitrary. They sort cleanly, they grep cleanly, and they survive copy-paste into Slack without auto-linking.

Naming conventions in lieu of tag dimensions

Velprove uses naming conventions instead of a separate tag UI, which means the dimensions you would otherwise tag get encoded into the name itself. A name like acme-co:prod:wp-admin-login:p1:kinsta packs five dimensions in one string: client (the slug), environment (prod, staging), check type (homepage-uptime, wp-admin-login, multi-step-checkout), criticality (p1, p2, p3), and hosting (wpengine, kinsta, cloudways, self-managed). The colon-delimited segments give you grep-style filters in any list view that supports text search. Knowing the site runs on WP Engine, for example, tells you to check whether Alternate Cron is enabled (it is opt-in there) before you escalate.

Why naming conventions beat folder-per-client at scale

Folders look tidy when you have 5 clients. At 50 clients with 4 monitors each, you are clicking into 50 folders to do anything. A flat list with a strict naming convention lets you ask the same questions with a text filter: type acme-co: and see every Acme monitor, type :p1: and see every p1 monitor across the book. The trade-off versus a tag UI is real but small, and the workflow is fast once it is muscle memory.

Tiered monitoring matched to your care plan tiers

A common industry pattern is to bundle WordPress care plans into three tiers. The dollar bands below are what most agencies are doing. Your monitoring should match the tier the client is paying for, not a one-size config that loses money on the bottom tier and underdelivers on the top.

Basic tier (HTTP uptime + SSL expiry) for $30 to $99 plans

At the $30 to $99 band the client is paying for plugin updates, backups, and a heartbeat. Monitoring should match: HTTP homepage check at a 5-minute interval, SSL expiry check, and a single email alert to the account manager. No paging. No browser sessions. The math has to work, and at $40/month you cannot justify a $5/month-per-monitor cost stack. Velprove's free tier handles this layer at zero cost per site.

Professional tier (add keyword + Velprove browser login monitor) for $99 to $199 plans

At the $99 to $199 band the client expects you to catch problems they would not catch themselves. That means a keyword check on the homepage (so a hacked site replacing your client's pharmacy with theirs gets flagged), and a browser login monitor against wp-admin. The browser login monitor is the differentiator. It is the difference between "the site is up" and "the client can actually run their business."

Premium tier (add multi-step API checks + 30-second intervals) for $200+ plans

At $200+ the client usually has WooCommerce, a membership system, or a custom API. Browser monitors with custom step sequences handle cart-to-checkout and member-login-to-dashboard flows when the path lives in the UI. Multi-step API monitors handle login-to-API-call chains where each step is an HTTP request and the next step uses a value extracted from the previous response. On Velprove Pro, HTTP monitors run as fast as 30 seconds and browser login monitors run every 5 minutes, which catches outages inside a single SLA window for the homepage and detects wp-admin lockouts within the same maintenance hour. Pager-grade routing is appropriate here. So is a branded status page on the client's own custom domain, covered below. Pro includes 10 of these, one per client across a 10-client book.

How do you monitor wp-admin with a real browser session?

This is the lead angle and the section worth reading twice. Most monitoring tools probe wp-admin with curl. Curl gets a 200, the dashboard goes green, and the client is locked out. The fix is monitoring wp-login.php with a real browser session that actually fills in the form, submits it, and waits for the wp-admin dashboard to render.

The cached-200 trap

Here is what goes wrong. Your client runs Cloudflare in front of WP Engine. Cloudflare has a page-cache rule that strips cookies on certain paths. A misconfigured rule, or a too-eager "cache everything" toggle, can land wp-admin in the cache. Now GET /wp-admin/ returns a cached 200 with the dashboard HTML, but only because that HTML was captured when an admin was logged in. A non-authenticated request to the origin would have been a 302 to wp-login.php. Your HTTP probe sees the cached 200 and reports green. Real users see a redirect loop or a blank page. A real browser session does not get fooled. It loads the page in a fresh session, finds the login form, submits credentials, and only reports green if the wp-admin dashboard actually loads.

Handling WPS Hide Login and Solid Security custom login URLs

WPS Hide Login (2 million+ active installs) lets your client move wp-login.php to /secret-door. Solid Security Hide Backend lets you set a custom login URL. Both break naive monitors that hardcode /wp-login.php. The right answer in your monitor configuration is to point the browser session at the actual custom URL the client is using, not to bypass the security plugin. Use a dedicated WordPress user with the Subscriber role for the monitor account. Subscriber has read-only dashboard access, which is enough to confirm login worked, and it cannot publish, install, or delete anything if the credential ever leaks. Never use a real admin credential for a monitor.

Why WordPress nonce expiry doesn't break a properly built login monitor

WordPress nonces have a 12 to 24 hour lifespan, invalidated on logout. People assume nonce expiry will break a long-running login monitor. It does not, because each monitor run starts a fresh browser session. New cookie jar, new login form load, new nonce, new submit. The nonce on every run is fresh. The pitfall is monitors that try to be clever by reusing sessions. Do not reuse sessions. The cost of one extra login per run is milliseconds. The benefit is a monitor that does not silently break at hour 13.

Where ManageWP, MainWP, and WP Umbrella stop short

This is not a knock on these tools. ManageWP is excellent for plugin updates and bulk backups. MainWP is excellent if you want a self-hosted control plane. WP Umbrella is excellent for client-friendly PDF reports. None of them, based on their public feature pages as of May 2026, run a real browser through wp-login.php to verify a working login. That is a real gap if you are selling premium-tier care plans where login uptime is the actual SLA.

The pricing model row matters more than agencies usually think. Per-site pricing grows linearly with your book and never stops. A flat $49 Pro plan is sized as a 10-client unit: 100 monitors total (about 10 per client), up to 10 of them browser login monitors (1 per client), and 10 branded custom-domain status pages (1 per client). One Pro plan fully covers 10 clients for $49 total, which is $4.90 per client per month with the browser login monitor and the branded status page included, not billed per probe. There is also the question of monitoring WordPress without installing another plugin on every client site. ManageWP and MainWP both need a worker plugin. Velprove probes from outside, so there is no plugin install, no auto-update window to worry about, and no plugin-conflict surface to debug.

Branded status pages on your client's custom domain

A branded status page on a client's own domain is the single highest-leverage thing you can add to a premium care plan. It moves the conversation from "is the site down?" to "here is the live status, here is the incident history, here is what we did about it." Clients stop asking. Account managers stop fielding the ask. The page does the work. Velprove Pro includes 10 status pages, each with custom-domain support and no Velprove branding. That is exactly 1 branded status page per client across a 10-client book, every client on their own domain, not just your top few.

What belongs on a client-facing status page

Less than you think. Current status (up, degraded, or down), the last 7 days of uptime, the last 3 incidents with a one-line summary, and a link to subscribe. That is it. Do not show the client your raw probe data. Do not show them a flame graph. Do not show them which monitor fired. Show them what they would tell their boss; what belongs on a public status page goes deeper on the layout decisions.

Custom domain + logo + incident history

The status page should live at status.clientdomain.com, not status.youragency.com/clients/acme. A custom subdomain on the client's own domain reinforces that you are an extension of their team. Add their logo and let the page show its rolling 30-day incident history. The incident history is the part clients actually screenshot for their own internal stakeholders. Make sure each incident has a clear start time, end time, and a one-paragraph postmortem.

One Pro plan = 10 fully branded clients, then a custom plan

The unit is deliberate. Pro's 10 status pages map 1-to-1 onto 10 clients, so every client on the plan gets their own branded page at status.clientdomain.com, not just the top tier. The same 10-client math runs through the rest of the plan: 100 monitors is about 10 per client (a few HTTP monitors for the homepage and key landing pages, 1 browser login monitor that proves wp-admin actually logs in, a couple of API monitors, a couple of multi-step monitors for checkout or the contact form), and the 10 browser login monitors are exactly 1 per client. One Pro plan is a 10-client book, fully covered and fully branded. Starter at $19/month is the same shape at 3 clients (3 status pages, 3 browser login monitors, 30 monitors at exactly 10 per client), which fits a freelancer or a small book.

Past 10 clients there is no trick and no self-serve workaround. Beyond the 10-client unit we build a custom plan around your specific client book, sized to exactly the roster you run, with full browser login monitoring and custom-domain status pages for every client. Get in touch and we will tailor it. The 10-client unit is the value story up to 10 clients. Larger books get a plan built for them.

How do you route alerts across 50+ sites without alarm fatigue?

Alarm fatigue is the silent killer of agency monitoring. If every alert pages everyone, the team starts ignoring alerts. The first time a real outage gets ignored, you have lost the client.

Per-monitor channel mix and the per-account-manager workaround

Each monitor in Velprove can pick its alert channels independently: email, Slack, Discord, Teams, PagerDuty, or a custom webhook. Slack, Discord, Teams, and PagerDuty each take a single destination configured once at the account level, so Velprove on its own routes every Slack alert to the same workspace channel. If your team needs per-account-manager Slack channels (Account Manager A's channel for Acme, AM B's for Beta), point Velprove's custom webhook at a small router (Zapier, n8n, or a 50-line agency proxy) that fans out by monitor name prefix. Email destinations are configured per user account, which covers solo or small teams cleanly.

Routing by criticality (page only for premium-tier sites)

Tag-based routing pays off here. p1 monitors page on-call through PagerDuty. p2 monitors post to a team Slack channel. p3 monitors send a daily digest email. A $30/month care-plan site at 3am is not a paging event. A $400/month WooCommerce site at 3am absolutely is. The routing rules should encode that distinction so a tired on-call engineer never has to make the call manually. The same logic applies to the WHMCS client portal monitoring guide if you also run hosting reseller infrastructure.

Pausing monitors during planned maintenance

Tuesday 2am plugin update window? Pause the relevant monitors before the window opens, re-enable when it closes. Velprove's active toggle on each monitor handles this manually today. Build the on-and-off into your maintenance runbook so the alert silence is a deliberate step in the change, not a thing someone has to remember at 1:55am. The rule of thumb: if you know in advance, pause in advance. If you pause after the alert fires, you have already woken someone up.

How do you send monthly client uptime reports at scale?

Monthly is the most common cadence for client uptime reports. Reports are how you prove the value the client is paying for. A care plan without a monthly report is a care plan the client forgets they are paying for, until renewal time.

What clients actually read

Clients read the headline number and the incident summary. That is it. The headline is "99.97% uptime this month." The incident summary is "one incident, 12 minutes, caused by a hosting provider outage in Frankfurt, resolved automatically." A 14-page report with response-time histograms gets skimmed for 8 seconds and filed in a folder nobody opens. Lead with the headline. Let the detail live in an appendix. If you need to sanity-check what a headline number translates to in real downtime minutes before you send the report, our uptime SLA calculator does the per-month and per-quarter math.

The status page IS the report

Most agencies overbuild the monthly report. The lowest-overhead version: send the client a one-paragraph email on the first of the month with the headline uptime number, the count and total minutes of incidents, and a link to their custom-domain status page where the incident history lives. The page is already up to date, it is the live artifact, not a snapshot. The email is a summary on top. Total time per client: under 5 minutes when the per-client status page is already running. Velprove does not auto-generate the email itself today, you write the paragraph from the dashboard data and send through your normal client-comms channel.

Weekly cadence as premium-tier differentiator

For premium-tier clients, send the same shape weekly instead of monthly. The cost is the same once the workflow is templated, you reuse the headline-paragraph format and let the page do the rest. The client gets a Friday-afternoon email with the week's uptime number and any incidents, plus the link to their status page. This positions the premium tier as "you hear from us proactively" versus the basic tier where the client only hears from you when something is wrong.

Free tier as the WordPress agency monitoring starting point

Velprove's free tier exists for exactly this kind of pilot. Free includes one browser login monitor (15-minute interval), multi-step API monitors (3 steps), and 5 regions. There is no credit card on signup, and the commercial-use side of free uptime monitoring is allowed.

How to pilot Velprove on 5 sites

Pick 5 representative sites: one basic-tier client, two professional-tier clients, two premium-tier clients. Set up HTTP monitors for all 5. Add the free tier's one wp-admin browser login monitor to your hardest-to-monitor premium client (the one whose admin you actually worry about). Add a multi-step API monitor for one premium client's API or login flow. Run for 14 days. Compare the alert quality to whatever you are using today. The browser login monitor is usually the moment the decision gets made, and Starter at $19 unlocks more browser slots once the workflow is proven.

When to graduate to Starter or Pro, with the worked math

Size the plan to the client count, not the raw site count. Starter at $19/month is a 3-client unit: 30 monitors total (exactly 10 per client), up to 3 of them browser login monitors (1 per client), 3 branded status pages, and 1-minute HTTP intervals. That fits a freelancer or a small book. Note that Starter status pages carry no Velprove branding but do not support a custom domain. Pro at $49/month is a 10-client unit: 100 monitors total (about 10 per client), up to 10 of them browser login monitors (1 per client), 10 branded status pages on the client's own custom domain, and 30-second HTTP intervals. Pro is the first tier with custom-domain status pages.

Here is the worked example. Take a 10-client book where each client gets a few HTTP monitors (homepage plus key landing pages), 1 browser login monitor that proves wp-admin actually logs in, a couple of API monitors, and a couple of multi-step monitors (checkout, contact form). That is about 10 monitors per client, 100 total, which is exactly Pro's ceiling. Add 1 browser login monitor per client (10 of 10) and 1 branded status page per client on status.clientdomain.com (10 of 10). Total cost: $49/month, flat, which is $4.90 per client per month for a fully covered, fully branded client.

Now scale it. Beyond 10 clients you do not piece together a bigger plan yourself. We build a custom plan around your specific client book, sized to exactly the roster you run, whether that is 18 clients or 60, with full browser login monitoring and a custom-domain status page for every client. Get in touch and we will tailor it. Compare per-site monitoring that keeps adding a dollar or two per site per month with no browser login monitor and no branded custom-domain status page. The Pro-unit value holds its shape up to 10 clients, and past that you get a plan built for the book instead of watching a per-site bill climb without a ceiling.

Frequently Asked Questions

Can I monitor 50+ WordPress sites on the free tier?

Velprove's free tier is built for piloting, not for running an entire agency book. You can absolutely set up 5 to 10 sites on free to validate the workflow, test the browser login monitor against your client stack, and prove the alerting routes work. For 50+ sites you will want Starter at $19 or Pro at $49 because of monitor count and interval-floor needs. The honest answer: pilot on free, graduate to paid once the workflow is proven. Commercial use is allowed on every tier.

How do I monitor wp-admin if my client uses WPS Hide Login or Solid Security?

Point your Velprove browser login monitor at the actual custom URL the security plugin is using, not at /wp-login.php. The monitor logs in through the same door real users do. WPS Hide Login (2 million+ active installs) and Solid Security Hide Backend both let you set a custom login URL. The monitor configuration stores that URL, plus a low-privilege Subscriber-role test account. Never use a real admin credential. If the credential ever leaks, a Subscriber role cannot publish, install, or delete anything.

How do I avoid alert fatigue when monitoring this many sites?

Three rules. First, route by criticality: p1 sites page on-call, p2 sites post to Slack, p3 sites send a daily digest. Second, pick the channel mix per monitor so basic-tier sites never trigger your PagerDuty rotation. Third, pause monitors before scheduled maintenance windows so plugin updates and redesign launches do not generate noise (Velprove's active toggle is a manual flip today). Together these rules turn a 50-site book from a 3am pager nightmare into a system where alerts that fire are alerts that matter.

What's the cost per site compared to ManageWP or WP Umbrella?

ManageWP is $1/site/month for uptime monitoring. WP Umbrella is around €1.99/site/month. Both keep adding cost per site with no ceiling. Velprove Pro is a flat $49/month and includes 100 monitors total, up to 10 of them browser login monitors, plus 10 branded status pages on custom client domains, at 30-second HTTP intervals. Pro is sized as a 10-client plan: about 10 monitors per client, 1 of which is a browser login monitor, and 1 branded custom-domain status page per client. So one Pro plan fully covers 10 WordPress clients for $4.90 per client per month. Starter at $19/month is the same shape at 3 clients. Beyond 10 clients we build a custom plan around your specific client book, sized to the roster you run. Email support@velprove.com and we will tailor it. Pro includes the browser login monitor and branded custom-domain status pages that ManageWP, MainWP, and WP Umbrella do not include based on their public feature pages as of May 2026.

Can I give each client their own white-label status page?

Yes. Pro includes 10 branded status pages, each with custom-domain support (so the page lives at status.clientdomain.com, not on a Velprove subdomain), client logo upload, and a rolling 30-day incident history on the public page, with no Velprove branding. That is exactly 1 branded custom-domain page per client across a 10-client book, every client on the plan, not just the top tier. The page shows current status, recent uptime, and incident summaries written for non-technical readers. Starter at $19/month is the same shape at 3 clients (3 branded status pages, no Velprove branding, no custom domain on Starter). For more than 10 clients we build a custom plan around your specific client book when you get in touch at support@velprove.com. Branded custom-domain status pages are a feature that ManageWP, MainWP, and WP Umbrella do not include based on their public feature pages as of May 2026.

Should I run weekly or monthly client uptime reports?

Monthly is the most common cadence and the right baseline for basic and professional care-plan tiers. Weekly is a low-cost differentiator for premium-tier clients because it positions the relationship as proactive rather than reactive. Use the per-client status page as the live artifact and send a one-paragraph headline email referencing it (uptime number, incident count and total minutes, link to the page). Velprove does not auto-generate the client email today, agency operators write the paragraph from the dashboard data and send via their normal client-comms channel. Total time per client per report should be under 5 minutes.

If you are running 30+ WordPress client sites and tired of HTTP probes that miss real failures, start a free Velprove account and pilot on a handful of sites this week. One browser login monitor, multi-step API monitors (3 steps), and 5-region coverage are all included on free. Start free or see pricing.