The Definitive Technical Guide
How to Monitor Hosting Uptime and Performance
The metrics that actually matter, the tools that check them, and how to set up alerts before your customers notice a problem instead of after
📋 What’s in this guide
- Why “It’s Probably Fine” Isn’t a Monitoring Strategy
- The Metrics That Actually Matter
- Synthetic Monitoring vs. Real User Monitoring
- Setting Up Uptime Monitoring: Step by Step
- Choosing a Monitoring Tool
- Reading Your Host’s Own Status Page
- What to Do When an Alert Fires
- Uptime SLAs: What They Actually Promise
- Monitoring Checklist
- Frequently Asked Questions
Most site owners find out their site is down the way everyone does: a customer emails, a colleague texts, or they happen to check the site themselves at the wrong moment. By the time a human notices organically, the outage has usually been running for minutes or hours, quietly costing sales, trust, and search visibility. Monitoring exists to close that gap — to tell you within seconds or minutes, not whenever someone happens to look.
This guide covers what to actually monitor, the difference between the two fundamentally different monitoring approaches, how to set up alerting in practice, and what your host’s uptime guarantee actually promises you when something goes wrong.
1. Why “It’s Probably Fine” Isn’t a Monitoring Strategy
Every host has outages. Even providers with excellent infrastructure experience occasional downtime — from routine maintenance windows to unplanned incidents at the data center level, sometimes entirely outside any individual host’s control. See our cloud outage research for how often this actually happens across major providers. The question isn’t whether an outage will ever happen; it’s how quickly you find out when it does.
The cost of not knowing compounds quickly. Our downtime cost research breaks down what an hour of unplanned downtime actually costs across different business sizes — and every hour that passes before you notice is an hour you can’t recover, whether or not you were watching.
It’s near-zero time-to-detection. You can’t prevent every outage, but a properly configured monitoring setup turns a silent, hours-long outage into a five-minute alert-and-fix cycle. That difference is almost entirely about whether you set up monitoring before you needed it.
2. The Metrics That Actually Matter
“Monitoring” gets treated as a single thing, but it’s really several different measurements, each catching a different failure mode.
| Metric | What It Catches | Typical Check Interval |
|---|---|---|
| Uptime / availability | The site is completely down or unreachable | Every 1–5 minutes |
| HTTP status code | The site loads but returns an error (500, 502, 503) instead of 200 OK | Every check, alongside uptime |
| Response time / TTFB | The site is technically up but degraded — slow enough to hurt conversions and Core Web Vitals | Every 1–5 minutes |
| SSL certificate expiry | A lapsed certificate that will break HTTPS access entirely | Daily |
| Domain expiry | An unrenewed domain that will take the entire site offline | Daily to weekly |
| DNS resolution | DNS misconfiguration or propagation issues making the site unreachable for some visitors | Every 5–15 minutes |
| Content/keyword check | The page loads with a 200 status but shows an error page, maintenance message, or defacement | Every check |
A misconfigured WordPress site can return a perfectly valid 200 OK while displaying “Error establishing a database connection” or a blank white screen. Basic uptime checks that only look at the HTTP status code miss this. A content or keyword check — confirming a specific string still appears on the page — catches failures that a status-code-only check would report as “up.”
3. Synthetic Monitoring vs. Real User Monitoring
These are two genuinely different techniques, and most serious setups eventually use both rather than picking one.
Synthetic Monitoring
An external service periodically sends requests to your site from its own servers — typically from multiple geographic locations — and measures the response, independent of whether any real visitor happens to be on the site at that moment. This is what catches an outage at 3am when no one is browsing. It’s proactive, consistent, and doesn’t depend on real traffic existing.
Real User Monitoring (RUM)
A small script embedded in your actual pages measures real visitors’ experience — their actual load times, their actual browsers and connection speeds, their actual geographic distribution. RUM tells you what your real audience is experiencing, which synthetic checks from a monitoring company’s data center can’t fully replicate. It’s also what Google’s Core Web Vitals field data is built from; see our Core Web Vitals and hosting guide for how that connects to search ranking signals.
For most small-to-mid-size sites, synthetic uptime monitoring is the non-negotiable first step — it’s what tells you the site is down at all. RUM is a valuable second layer once you’re optimizing performance for real visitors, but it isn’t the thing standing between you and a multi-hour undetected outage.
4. Setting Up Uptime Monitoring: Step by Step
Pick a monitoring service and create an account
Any reputable uptime monitor works for this step — see Section 5 for how to choose between them. Most offer a free tier sufficient for monitoring one or a handful of sites.
Add your site’s URL as a monitor
Use the actual homepage URL visitors use (with HTTPS), not an internal or staging URL. If you have multiple critical pages — a checkout page, a login page — add each as its own separate monitor rather than relying on the homepage to represent the whole site.
Set the check interval and check type
1–5 minutes is standard for a production site. Choose an HTTP(S) check with status-code validation at minimum; add a keyword/content check if your monitoring service supports it, per the warning in Section 2.
Configure alert channels
Email alone is easy to miss during an actual outage, since email delivery can itself be delayed or land in spam. Add at least one immediate channel — SMS, a phone call, or a push notification through a dedicated app — for anything you’d classify as a real emergency.
Add SSL and domain expiry monitoring
Most monitoring services offer this as a separate, low-frequency check. An expired SSL certificate or an unrenewed domain are two of the most common causes of a completely preventable, self-inflicted outage.
Test the alert before you need it
Deliberately trigger a failure (or use the service’s test-alert feature) and confirm the alert actually reaches you, on the device you’d realistically have with you. An alerting system no one notices in a real emergency provides no more protection than having none.
5. Choosing a Monitoring Tool
The uptime monitoring market has genuine, well-established options at every budget level, from free single-site checkers to enterprise observability platforms. Rather than recommending a specific vendor whose pricing and features will shift, evaluate any candidate against this list:
- Check interval available on your plan tier (1–5 minutes for production sites; longer intervals delay detection)
- Multiple check locations, so a single region’s network issue doesn’t produce a false alarm
- Multiple alert channels (email, SMS, phone call, push, and integrations like Slack or PagerDuty)
- Public status page generation, if you want to communicate incidents to your own users
- SSL and domain expiry monitoring included, not a separate paid add-on
- Historical uptime reporting, so you can verify your host’s actual uptime against its advertised SLA (Section 8)
6. Reading Your Host’s Own Status Page
Most hosting providers maintain a public status page showing known incidents and scheduled maintenance across their infrastructure. This is a genuinely useful first check when your independent monitoring alerts you to a problem — it tells you within seconds whether the issue is host-wide (nothing you can fix from your end except wait) or specific to your account (something worth investigating or opening a support ticket about).
Bookmark your host’s status page before you need it, and check it first during any alert — it can save you from debugging your own site for an issue that’s actually happening one layer up, on infrastructure entirely outside your control.
7. What to Do When an Alert Fires
- Check your host’s status page first (Section 6) — rule out a known, host-wide incident before debugging your own configuration.
- Confirm it’s not a false positive — load the site yourself from a different network (mobile data, not the same WiFi as your monitoring check) to rule out a local or regional network issue.
- Check what actually changed recently — a plugin update, a theme change, a new deployment, or a DNS change are the most common causes of a self-inflicted outage.
- Consult our common hosting errors guide if you’re seeing a specific error code or message — it maps the most frequent errors to their actual causes and fixes.
- Open a support ticket with specifics if the cause isn’t obvious — the exact error message, the time it started, and what (if anything) changed beforehand, rather than just “my site is down.”
8. Uptime SLAs: What They Actually Promise
Most hosts advertise an uptime guarantee, commonly 99.9%. It’s worth understanding what that number actually means before treating it as a promise of near-perfect reliability. See our uptime explained guide for the full breakdown of what different uptime percentages translate to in actual annual downtime minutes.
| Advertised Uptime | Downtime Allowed Per Year |
|---|---|
| 99% (“two nines”) | ~3.65 days |
| 99.9% (“three nines”) | ~8.76 hours |
| 99.95% | ~4.38 hours |
| 99.99% (“four nines”) | ~52.6 minutes |
Read the actual SLA language, not just the advertised percentage. Most hosting SLAs remedy a breach with a service credit (a partial refund or account credit toward future billing) rather than compensation for any business impact the downtime caused. Independent monitoring (Section 4) is what lets you actually prove downtime occurred and claim the credit you’re entitled to — without your own logs, you’re relying on the host’s own reporting of its own outage.
9. Monitoring Checklist
- Uptime monitor configured on the live production URL, checking every 1–5 minutes
- Content or keyword check enabled, not just HTTP status code
- Checks running from multiple geographic locations
- At least one immediate alert channel configured (SMS, call, or push) beyond email alone
- Alert delivery actually tested, on the device you’d have with you
- SSL certificate expiry monitoring enabled
- Domain expiry monitoring enabled or tracked separately
- Host’s status page bookmarked for quick reference during an incident
- SLA terms read and understood, including what remedy is actually offered
10. Frequently Asked Questions
Is my host’s own uptime reporting trustworthy?
Treat it as one data point, not the full picture. A host reporting its own uptime has limited incentive to report every brief blip, and its measurement methodology may differ from an independent check. Running your own third-party monitoring gives you an independent record you control, which matters both for catching real problems and for substantiating an SLA credit claim.
How many monitoring checks do I actually need for a small site?
One solid uptime check on the homepage, plus one on any business-critical page (checkout, login, a key landing page), covers most small sites adequately. Scale up the number of monitors as the site grows more complex, rather than starting with none.
Can monitoring itself slow down my site?
A properly configured synthetic monitor checking every 1–5 minutes adds a negligible, essentially unmeasurable load to your server — it’s a single request, no different from a normal visitor’s page load. This isn’t a reason to avoid monitoring or to check less frequently than you actually need.
What response time counts as “slow enough to worry about”?
There’s no universal number, but Google’s own Core Web Vitals guidance treats a Largest Contentful Paint over 2.5 seconds as needing improvement, and TTFB is usually the largest hosting-controlled contributor to that number. See our Core Web Vitals and hosting guide for specific TTFB targets and what typically causes it to slip.
Should I monitor from inside my own network or use an external service?
External, third-party monitoring is what actually matters, because it tests your site the way a real visitor reaches it — over the public internet, from outside your own infrastructure. Checking availability only from inside your own office or server network can miss DNS, routing, or firewall issues that only affect outside visitors.
You Can’t Fix What
You Don’t Know Is Broken.
Uptime and performance monitoring isn’t a nice-to-have reserved for large businesses — it’s a five-minute setup, often free at the scale most small sites need, that converts a silent, hours-long outage into an alert you can act on immediately. The gap between those two outcomes is entirely about whether you configured monitoring before the outage, not during it.
Start with basic uptime and status-code checks today, add SSL and domain expiry monitoring, and test that alerts actually reach you. Everything past that is refinement.
Know first.
Fix fast.