To monitor WordPress uptime, you run an external service that requests each site’s URL on a set interval (every 1–5 minutes), confirms it returns an HTTP 200 with expected content, and alerts you when it doesn’t. Free tools like UptimeRobot cover a handful of sites; agencies managing dozens or hundreds need a self-hosted dashboard that checks every site in parallel without per-site fees.
If you manage WordPress sites for clients, downtime is a business problem, not just a technical one. A site that’s down during a product launch or a Monday-morning lead rush costs the client money and costs you trust. This guide covers how to monitor WordPress uptime properly, the free route, the at-scale route, and the settings that separate real monitoring from noisy false alarms.
Why uptime monitoring matters for agencies
The core value of monitoring is simple: you should know a client site is down before the client does. Getting a “your website is broken!” email from a client is the worst way to learn about an outage, it means your monitoring failed or didn’t exist.
Beyond the obvious revenue and reputation cost, uptime monitoring gives you:
- SLA evidence. If you promise 99.9% uptime, you need data to prove it (and to spot a flaky host before renewal).
- Early warning of deeper problems. A site that goes down briefly every afternoon often points to a memory limit, a runaway cron job, or a host that’s overselling resources.
- Response-time trends. A site creeping from 400 ms to 2.5 s isn’t down, but it’s degrading, and slow load times hurt conversions and SEO.
Free ways to monitor WordPress uptime
You don’t need to spend anything to start. Several services have genuinely useful free tiers:
| Tool | Free tier | Min interval (free) | Best for |
|---|---|---|---|
| UptimeRobot | 50 monitors | 5 minutes | Freelancers, a handful of sites |
| BetterStack (Better Uptime) | 10 monitors | 3 minutes | Nice incident UI, status pages |
| HetrixTools | Up to ~40 monitors | 1 minute | Faster checks on a free plan |
| Uptime Kuma (self-hosted) | Unlimited | Configurable (20s+) | Devs comfortable running their own server |
For a quick manual spot-check from your own machine, you can confirm a site is responding with a single command:
curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://clientsite.comA response of 200 0.642s means the homepage loaded in 642 ms and returned OK. That’s fine for one-off checks, but it doesn’t scale or alert you, which is the whole point.
The catch with free tools at scale
Free monitoring breaks down once you’re past a dozen or so sites. UptimeRobot’s free plan caps you at 5-minute intervals and 50 monitors; jumping to 1-minute checks or 50+ sites pushes you onto paid plans that bill per monitor. Run the math across 200 client sites and a third-party monitor can cost more per year than the rest of your tooling combined. That per-site pricing model is exactly what makes uptime monitoring expensive for agencies.
How to monitor many client sites without per-site cost
The way to escape per-site billing is to run monitoring yourself from a single dashboard that checks every site you manage. Two common approaches:
- Self-hosted monitor (e.g. Uptime Kuma). Free and unlimited, but it only knows about uptime, it has no idea whether a site needs a plugin update, has stale backups, or is throwing a PHP error behind a working homepage.
- A WordPress management dashboard. Tools in the MainWP/ManageWP category fold uptime monitoring into a control panel that also handles updates and backups across all your sites.
This is where Siteward fits. It’s a lean, self-hosted WordPress management dashboard (one plugin on your control site, a child plugin on each managed site). The uptime checker hits each client’s public URL directly with a parallel request engine, so a full outage is caught even when WordPress itself is down. Crucially, it manages unlimited sites for one flat price with no per-site fees, the free dashboard covers uptime and update monitoring across every site, and the Agency and Lifetime tiers add backup-health and Zapier alerting. Because it’s self-hosted, all your monitoring data stays on your own server. See the full feature list or how it compares as a MainWP alternative.
Setting good check intervals and retries (avoid false alarms)
The fastest way to make your team ignore monitoring is to flood them with false alerts. A short network blip, a CDN hiccup, or a single timed-out request will trip a naive monitor. The fix is intervals plus retries.
Check interval
- 1–2 minutes for high-value e-commerce or lead-gen sites where every minute of downtime matters.
- 5 minutes is a sensible default for the bulk of brochure and content sites, it keeps load on your monitor low and is plenty fast for most SLAs.
Retries and confirmation
Never alert on a single failed check. Configure the monitor to retry 2–3 times with a short delay (10–30 seconds) before declaring a site DOWN. A site is only “down” if it fails the retry sequence, this single setting eliminates the vast majority of false alarms while still catching real outages within a minute or two. Apply the same logic in reverse: only fire the “back up” alert after one clean check, so you don’t flap between states.
Alert routing: email, Slack, and Zapier
An alert nobody sees is useless. Route notifications to where your team actually works, and fire them on state transitions (down → up, up → down) rather than every single check cycle:
- Email, the baseline; goes to whoever owns the account.
- Slack / Microsoft Teams, a dedicated
#site-alertschannel so the whole team sees it in real time. - Zapier / webhooks, the flexible glue. Pipe an outage into a Zap that creates a ticket in your help desk, texts the on-call dev via SMS, or logs the incident to a spreadsheet. Siteward’s Pro tiers push a non-blocking webhook to Zapier on each transition, so you can build whatever escalation flow your agency runs.
Tip: route by severity. A hard-down site should page someone; a “slow load” warning can sit quietly in a digest.
Detecting “up but broken” vs hard-down
This is the gap most basic monitors miss. A WordPress site can return an HTTP 200 and still be completely broken, the dreaded “There has been a critical error on this website” white screen, a fatal PHP error after a bad plugin update, or a homepage that loads while checkout throws a 500.
To catch “up but broken,” your monitoring needs to go beyond a status code:
- Keyword/content checks. Confirm the response contains expected text (e.g. your client’s tagline) or does not contain failure strings like “critical error” or “Error establishing a database connection.” Most monitors support this.
- Critical-error detection from inside WordPress. The most reliable signal comes from the site itself reporting its health. Siteward’s child plugin surfaces critical errors and even names the culprit, the specific plugin or theme that triggered the fatal, so you’re not guessing which of 40 plugins broke after an update.
- WP-CLI on the server for a definitive answer when you suspect a fatal:
wp eval 'echo "ok";'will surface PHP fatals that a browser hides, andwp plugin list --status=activehelps isolate a bad activation.
Pairing an external uptime check (catches hard-down even when WordPress is dead) with an internal health check (catches up-but-broken) gives you complete coverage. That combination is exactly what a management dashboard is built to provide.
A practical monitoring setup for an agency
- External uptime check on every site, 1–5 min interval, 2–3 retries before alerting.
- Content/keyword check to catch critical-error white screens.
- Internal health reporting from each site (updates pending, cron health, backup status).
- Alerts routed to Slack + email on transitions, with Zapier for escalation.
- One dashboard so adding the 201st site costs nothing extra.
If you’re outgrowing per-site monitoring tools, compare the flat-rate Siteward pricing against what you’re paying per monitor today, for most agencies past 20–30 sites, a self-hosted dashboard pays for itself quickly.
FAQ
What is the best free way to monitor WordPress uptime?
For a small number of sites, UptimeRobot’s free plan (50 monitors, 5-minute checks) is the easiest start. If you’re comfortable running a server, self-hosted Uptime Kuma is free and unlimited. For many client sites, a self-hosted WordPress dashboard like Siteward monitors unlimited sites at no per-site cost.
How often should I check a WordPress site for uptime?
Every 1–2 minutes for high-value e-commerce or lead-generation sites, and every 5 minutes for typical brochure and content sites. Always require 2–3 retries before declaring a site down so a brief network blip doesn’t trigger a false alarm.
How do I detect a WordPress site that is “up but broken”?
A status-code check isn’t enough because a broken site can still return HTTP 200. Add a keyword/content check that confirms expected text is present (or that failure strings like “critical error” are absent), and use internal health reporting from the site itself. Siteward detects critical errors and names the plugin or theme that caused them.
Can I monitor uptime for hundreds of WordPress sites without paying per site?
Yes. Third-party monitors usually bill per monitor, which gets expensive at scale. A self-hosted dashboard such as Siteward checks every site in parallel for one flat price with no per-site fees, keeping your monitoring data on your own server.
Why use retries before sending a downtime alert?
A single failed check is often just a transient timeout, CDN hiccup, or network blip rather than a real outage. Retrying 2–3 times with a short delay before alerting eliminates most false alarms while still catching genuine downtime within a minute or two.