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

Bottom line: WordPress agencies running 50+ client sites 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 is a solo-founder-built monitor with a free browser login monitor on every plan, 30-second HTTP intervals on Pro ($49/month), and 3 branded status pages on custom client domains. Free tier covers a 5-site pilot with no credit card.

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 a custom domain, covered below for premium clients specifically (Pro includes 3 of these).

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. At 50 sites, $1/site/month is $50/month and grows with your book. A flat $49 Pro plan covers up to 100 monitors total, so a 50-site book with one HTTP monitor per site plus 10 browser login monitors on your premium clients fits cleanly. The cost-per-site keeps falling as you fill the plan. 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 3 status pages with custom-domain support, which is the right shape for an agency: branded pages for your top 3 premium clients, and a single agency-internal dashboard for the rest of the book.

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, pick a light or dark theme, 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.

Which 3 clients get the dedicated page

A $30/month care-plan client does not need a branded status page. They need an email when the site goes down. Save the dedicated custom-domain pages for your top premium-tier clients, the ones whose internal stakeholders ask "how is the site doing" on a regular cadence and screenshot the status page for their own boss. The other 47 clients in the book get a single agency-branded internal status page (or a tagged group view inside the dashboard) that the agency team uses for triage, not for client-facing reporting. The 3-page cap on Pro is enough because most agency books have a 3-tier shape, and only the top tier actually pays for the white-glove deliverable.

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.

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

Starter at $19/month makes sense around 15 to 25 sites or when you need 1-minute HTTP intervals (Starter includes 25 monitors, 3 browser login monitors at 10-minute intervals). Pro at $49/month makes sense at 30+ sites, when you need 30-second HTTP intervals on premium clients, when you want up to 10 browser login monitors, or when you need branded status pages on custom domains. Pro includes 100 monitors, 10 browser login monitors at 5-minute intervals, and 3 status pages. The break-even versus per-site pricing happens fast. At 50 sites, ManageWP's $1/site/month is $50/month for HTTP-only monitoring with no browser login monitor and no branded status pages. Pro at $49/month covers all of it.

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, so 50 sites is $50/month. WP Umbrella is €1.99/site/month, so 50 sites is around €100/month. Velprove Pro is a flat $49/month and includes 100 monitors, 10 browser login monitors, 3 branded status pages, and 30-second HTTP intervals. The math fits a 50-site book if you run an HTTP monitor on every site, layer browser login monitors on your top 10 premium accounts, and reserve the 3 branded status pages for your top 3 white-glove clients. Pro lands at roughly the same cost as ManageWP's HTTP-only tier and roughly half the cost of WP Umbrella, with capabilities neither of them include.

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

Pro includes 3 branded status pages with custom-domain support (so the page lives at status.clientdomain.com, not on a Velprove subdomain), client logo upload, a light or dark theme, and a rolling 30-day incident history on the public page. That is the right shape for an agency: white-glove pages for your top 3 premium clients, and a single agency-internal dashboard or shared status page for the rest of the book. The page shows current status, recent uptime, and incident summaries written for non-technical readers. This is a real differentiator at the premium care-plan tier and 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.