If your website goes down at 2 a.m., how do you find out? For many businesses the honest answer is "when a customer complains", which may be hours later, after lost orders and enquiries. Uptime monitoring checks your site from the outside at regular intervals and alerts you the moment it stops responding properly. It is one of the cheapest and most effective safeguards a business with an online presence can put in place.
Why uptime monitoring matters
- Faster response: the length of an outage is largely determined by how long it takes someone to notice. Monitoring shrinks that to minutes.
- Evidence: a record of outages and response times lets you hold hosting providers to their SLAs and spot patterns, such as slowdowns every night during backups.
- Catching quiet failures: expiring certificates, broken checkout pages and failed scheduled jobs often do not take the whole site down, yet still cost money.
- Confidence during changes: after a deployment or migration, monitoring confirms everything stays healthy.
Monitor from outside your infrastructure
A monitor running on the same server as your website cannot report that the server is down. Use an external service, or at least a separate server in a different data centre or provider. Good monitoring services check from multiple locations and only alert when several agree, which filters out network glitches between one checking location and your server.
Types of uptime checks
| Check type | What it verifies | Use it for |
|---|---|---|
| HTTP(S) status | The URL returns an expected status code, usually 200, within a time limit | Home page, key landing pages, APIs |
| Keyword | The page contains (or does not contain) specific text | Detecting error pages that still return 200 |
| SSL certificate | Certificate valid, matching the domain, and not near expiry | Every HTTPS hostname you operate |
| Port / TCP | A port accepts connections | Mail servers, databases on private monitors, SSH |
| Ping (ICMP) | The host responds to ping | Network-level reachability (some hosts block ping) |
| DNS | A record resolves to the expected value | Detecting hijacks or accidental DNS changes |
| Heartbeat / cron | Your job pings the monitor on schedule; silence triggers an alert | Backups, scheduled imports, queue workers |
| Transaction / synthetic | A scripted browser logs in, searches or checks out | Critical user journeys |
Why keyword checks matter
Many failures return a perfectly healthy 200 OK: a CMS showing "Error establishing a database connection" with the wrong status code, a hosting suspension page, or a blank page from a PHP fatal error. Checking for a phrase that only appears on the working page, such as your footer's company name or a product heading, catches these.
Heartbeat monitoring for background jobs
Instead of the monitor calling your server, your job calls the monitor when it succeeds. If no ping arrives within the expected window, you get an alert. Add it to the end of a backup script:
#!/bin/sh
set -e
/usr/local/bin/run-backup.sh
curl -fsS -m 10 --retry 3 https://monitor.example.com/ping/your-check-id > /dev/nullBecause of set -e, the ping is only sent if the backup command succeeds. This pattern catches the failure that ordinary monitoring misses: the job that silently stopped running.
Choosing check intervals and timeouts
- Interval: one to five minutes suits most business websites. Shorter intervals detect outages sooner but generate more requests.
- Timeout: set it longer than your slowest normal response, perhaps 10 to 30 seconds, so slow pages are not reported as down. Track response time separately.
- Confirmation: require a failure from two or more locations, or two consecutive checks, before alerting.
- SSL warnings: alert at around 21 and 7 days before expiry, even when renewal is automated. Automated renewals do fail. You can check any site manually at any time with our SSL checker.
Alerting that people will act on
- Route by urgency: site down goes to phone (SMS, call or push app); certificate expiring in 21 days goes to email or a chat channel.
- Name a responder: an alert sent to a shared inbox nobody watches at night is not an alert. Agree who is on call, including weekends.
- Include context: the URL, error, location and time, plus a link to a short runbook of first steps.
- Send recovery notices so everyone knows when the problem has cleared.
Diagnosing an alert quickly
When a check fails, a few quick tests narrow it down:
curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://www.example.com/
dig +short www.example.com
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -datesThese show the status code and response time, the IP the domain resolves to, and the certificate's validity dates. Our HTTP header checker and DNS lookup tools give the same answers from a browser, useful when you are away from a terminal.
Status pages
A public status page, hosted separately from your main infrastructure, tells customers you know about a problem and reduces support calls during incidents. Many monitoring services can generate one from your checks automatically.
Uptime monitoring is not the whole picture
External checks tell you that something is wrong; internal server monitoring of CPU, memory, disk and services tells you why. Use both. If you would like monitoring and alert response handled for you around the clock, see our server management service.
Key takeaways
- Uptime monitoring alerts you to outages in minutes instead of waiting for customer complaints.
- Monitor from outside your infrastructure, from several locations, with confirmation before alerting.
- Go beyond status codes: keyword, SSL expiry, DNS and heartbeat checks catch quieter failures.
- Route alerts by urgency to a named responder, and pair external checks with internal server monitoring.