Interval, location, and the alerts you learn to ignore
WordPress Uptime Monitoring: Interval, Location, False Alarms
Perform uptime monitoring on a WordPress site at an interval that catches what actually happens to it. A five-minute check misses a four-minute outage entirely, and a single probe location reports a regional routing fault as a total outage. Sampling interval, probe count and confirmation rules together decide what you detect and what you never hear about.
Uptime monitoring checks that a WordPress site answers, at a fixed interval, from one or more locations. A five-minute interval misses every outage shorter than five minutes. A single probe location reports regional routing faults as downtime. Confirmation from a second location removes most false alarms.
Tick what you already do
- A five-minute check cannot detect a four-minute outage, and short outages are the common ones
- A single probe reports its own connectivity problems as your downtime
- Unconfirmed alerts are mostly false, and false alerts are how real ones get ignored
- The root can answer while every page that matters is failing
- A WordPress fatal error commonly returns HTTP 200 with an empty body, and status-only monitoring calls that up
- Every browser refuses the site at once, on a date that was known months in advance
- The one outage no backup and no rollback can undo
- Detection with no response buys nothing over waiting for a customer to email
- The alert lands with someone asleep and stops there
- Alert fatigue: after the fourth false alarm the real one gets swiped away
Tick the tasks you already run. Where you stand, what the gaps cost and which ones matter appear here.
How often each task is actually due
| What is checked | Interval | What that interval catches |
|---|---|---|
| HTTP availability | 60 seconds | Any outage of a minute or more; shorter ones remain a gamble |
| Keyword present in the response | 60 seconds, same request | White screens and database errors that still return HTTP 200 |
| Full page load time | 5 minutes | Degradation, while it is still degradation and not an outage |
| SSL certificate expiry | Daily | Thirty days of warning on a 90-day certificate |
| Domain registration expiry | Daily | The one outage a backup cannot undo |
| Alert log review, false alarms included | Monthly | Alert fatigue, which is what makes a real alert get ignored |
What the percentages actually mean
Availability targets are easier to agree to than to understand. Over a 30-day month: 99% allows just over seven hours of downtime, 99.9% allows about 43 minutes, 99.95% allows about 22 minutes, and 99.99% allows roughly four. Each additional nine costs roughly ten times as much to deliver.
Two of those numbers matter for most WordPress sites. Anything at or below 99% is a site with a real problem. Anything above 99.95% is a hosting and architecture conversation, not a monitoring one.
A 200 response is not a working site
The most common failure in WordPress monitoring is that the monitor is watching the wrong thing. A status check confirms the web server answered. It says nothing about whether WordPress rendered, whether the database responded, or whether the checkout completed.
A fatal PHP error in a plugin often returns HTTP 200 with an empty body. A database connection error returns a page — a real page, with a status code the monitor is happy with. Both read as up.
The fix takes one setting: have the check match a string in the response that only appears when the page genuinely works. A product name on a category page, the word in the checkout button, a footer element rendered from the database. Status plus content is a real check; status alone is a network test.
Interval and location are the two dials
Interval sets the longest outage you accept not hearing about. A five-minute check cannot detect a four-minute outage, and short outages are common: a PHP-FPM pool exhausting itself under a traffic spike, a cron job locking a table, a memory limit hit during an update.
Location sets your false-alarm rate. One probe reports its own network problems as your downtime, and the alert arrives at four in the morning for a site that never went down. Three locations with two-location confirmation costs one extra check cycle of delay and removes most of that noise.
False alarms are a cost, not a nuisance
Every false alert spends trust. After the fourth one, the person on call reads the subject line and swipes it away, and that is the state the system is in when the real outage arrives. Alert fatigue is not a personality flaw; it is a predictable response to a monitor that cries wolf.
Treat every false alarm as a defect with a cause: a timeout set too aggressively for a slow admin page, a single unreliable probe, a nightly backup that spikes response time past the threshold. Tune it, and the alerts that remain get read.
Monitoring shortens outages, it does not prevent them
An alert is worth exactly as much as the response behind it. A notification at 3am that reaches a phone nobody checks until 8am has bought nothing over a customer email.
What turns detection into recovery is prepared: a rollback point taken before every change, hosting access ready, a named person with an escalation path, and a runbook for the three failures that actually recur on that site. Monitoring tells you when to start. Everything after that is preparation you did earlier.
Monitoring reports what happened. Deciding what to do about it on a schedule is the maintenance checklist, and the whole routine is on the WordPress maintenance guides.
The procedure, step by step
- Decide what counts as downAn HTTP 200 is not the same as a working site. A WordPress install with a fatal error in a plugin frequently returns 200 with an empty body, and a status-only monitor calls that up. Define down as the checkout page failing to contain the word Checkout, not as the server failing to answer.
- Set the interval against what an outage costsThe interval is the maximum outage you accept not knowing about. Five minutes is fine for a brochure site. On a store taking orders continuously, five minutes of silent checkout failure is the whole point of monitoring, missed.
- Check content, not just statusRequest a page that exercises the database and match a string that only renders when the page is genuinely working. This is the single change that separates monitoring which catches white screens from monitoring which reports a broken site as healthy.
- Require confirmation from a second locationA single probe reports its own network problems as your outage. Every alert confirmed from a second, distant location before it fires removes most false alarms without adding meaningful delay — typically one extra check cycle.
- Route the alert to a person, with an escalation pathEmail alone fails overnight, which is when unattended outages run longest. Push, SMS or a paging rotation, and a second contact who is notified when the first does not acknowledge inside a set window.
- Review the false alarms monthlyEvery false alarm trains someone to dismiss the next notification. Track them, find the cause — an over-eager timeout, a single flaky probe, a cron job that spikes response time — and tune it out. Monitoring nobody trusts is monitoring nobody reads.
Tools worth using, and what each misses
| Tool | What it does well | What it misses |
|---|---|---|
| UptimeRobot | Free tier covers 50 monitors; simple to set up | Five-minute interval on the free plan, and weaker multi-location confirmation |
| Better Stack | 30-second checks, on-call rotation, hosted status pages | Priced per monitor, which adds up across a portfolio |
| Pingdom | Long retention and multi-step transaction checks | Expensive, and the check interval is tied to the plan tier |
| StatusCake | Multi-location confirmation available on lower tiers | Alerting rules are less flexible than the alternatives |
| A host's built-in monitoring | Zero setup, already running | Reports the server as up while the application returns a 500 — it watches its own layer, not yours |
When it needs handing over
WordPress availability monitoringGet WordPress uptime monitoring that wakes a person instead of filling a dashboard. Checks run every minute from three regions, two consecutive failures page an on-call…
More guides
Questions people ask before calling
How much downtime does 99.9% actually allow?
About 43 minutes a month, or just under nine hours a year. 99.95% halves that to roughly 22 minutes a month. The difference between those two numbers in a contract is the difference between one bad afternoon and several.
Is a one-minute interval worth paying for?
On a site that takes orders, yes — the interval is the outage length you accept not knowing about. On a brochure site with no transactions, five minutes costs nothing meaningful.
Why does my monitor say the site is up when it is clearly broken?
Because it is checking the HTTP status and nothing else. A WordPress fatal error commonly returns 200 with an empty body. Add a keyword match against text that only appears when the page renders properly.
How many probe locations do I need?
Three is the practical minimum, on different networks, with alerts requiring agreement from two. One location turns its own connectivity problems into your incidents.
Does monitoring prevent downtime?
No. It shortens it. The value is entirely in how fast someone finds out and how fast they can roll back, which is why an alert with no rollback plan behind it is half a system.