Reliable website uptime monitoring is more than checking whether a homepage loads. This runbook shows you how to monitor HTTP responses, DNS, SSL, hosting alerts, and regional availability; distinguish a local problem from a wider outage; and document the response so the next incident is faster and less disruptive.
Overview
Every website can experience an interruption, including sites running on managed hosting, cloud web hosting, or a small-business hosting plan. The goal is not to assume that an outage can always be prevented. The goal is to detect meaningful failures quickly, identify their scope, communicate clearly, and restore service using a repeatable process.
A useful website uptime monitoring setup uses more than one signal. An external HTTP check can confirm whether visitors reach the site, while hosting-panel alerts can reveal resource exhaustion, deployment failures, or platform maintenance. DNS monitoring helps identify domain-resolution problems, and certificate checks can warn about an HTTPS failure before browsers begin rejecting connections. These signals answer different questions and should not be treated as interchangeable.
Keep an operational record for each incident. Record the start time, symptoms, checks performed, actions taken, restoration time, and likely cause. A simple log is valuable for recurring outages, hosting discussions, technical SEO reviews, and decisions about whether your current hosting setup remains appropriate.
What to track
HTTP availability and response behavior
Monitor the public URL over HTTPS and check both the status code and response time. A check that only looks for a successful connection may miss an application returning an error page with an unexpected status. Where possible, monitor a representative page or health endpoint as well as the homepage. Test important paths such as a contact form, login page, checkout flow, or API endpoint separately because the homepage can remain available while a key function is broken.
DNS resolution
Check that the domain resolves to the expected records from more than one network or monitoring location. A DNS failure may affect some visitors while leaving the site accessible to others. Compare the results with your intended A, AAAA, CNAME, or other relevant records. If you recently changed providers or followed a DNS setup guide, confirm that old and new records are not conflicting.
SSL and certificate status
Track certificate expiry, hostname coverage, and whether the site presents a valid certificate over HTTPS. An expired or misconfigured certificate can make an otherwise healthy server appear unavailable to visitors. For renewal procedures and browser-related symptoms, use the SSL certificate renewal and HTTPS troubleshooting guide.
Hosting and infrastructure signals
Enable alerts from your hosting control panel, cloud provider, CDN, database, and deployment system where available. Track resource warnings such as CPU, memory, storage, connection limits, or unusual traffic. These alerts may explain a slow or intermittent site before a complete outage occurs. Review whether your hosting includes useful features such as automated backups, health checks, staging, and status notifications; the cloud hosting plan comparison guide provides a framework for evaluating those capabilities.
Monitoring-frequency comparison
| Check interval | Best use | Trade-off |
|---|---|---|
| 1–5 minutes | Revenue-generating sites, critical services, and active incidents | More alerts and greater sensitivity to transient failures |
| 5–15 minutes | Most business websites and production applications | Balances detection speed with manageable notifications |
| 30–60 minutes | Low-traffic informational sites and secondary environments | May delay awareness of a short outage |
| Manual checks | Planned releases, DNS changes, and incident verification | Cannot replace continuous external monitoring |
Use an alert delay or consecutive-failure rule where your monitoring service supports it. One failed request can result from a temporary network path problem; repeated failures from multiple locations are more actionable.
Cadence and checkpoints
Set a routine that covers both automated monitoring and human review:
- Continuously: Run external HTTP, DNS, and certificate checks. Route alerts to at least two responsible contacts when the site is important to customers.
- After every deployment: Test the homepage, key forms, authentication, redirects, static assets, and any connected API. Review logs for new errors and confirm that monitoring still reaches the production URL.
- Monthly: Trigger a controlled alert test, verify that notifications arrive, review false positives, and check that escalation contacts are still valid. Confirm that backup and recovery information is accessible; see the website backup and disaster recovery checklist.
- Quarterly: Review uptime history, response-time patterns, recurring status codes, hosting capacity, DNS records, certificate coverage, and monitoring locations. Remove obsolete checks and add checks for newly important user journeys.
- After an outage: Preserve timestamps, provider notifications, logs, screenshots, and relevant deployment details before closing the incident.
Keep an escalation list with the hosting provider, DNS provider, CDN, domain registrar, application owner, and business contact. Include account identifiers and the approved communication channel, but never store passwords or private keys in the runbook.
How to interpret changes
When an alert arrives, first confirm the symptom from a separate network or monitoring location. If the site loads on your office connection but fails externally, test from a mobile connection and review DNS results. A local failure may involve a router, firewall, cached DNS response, VPN, or corporate filtering rather than the hosting platform.
If several independent locations report HTTP failures, inspect the hosting dashboard, provider status page, recent deployments, application logs, and resource alerts. A 5xx response generally points toward the server or application path, while a 4xx response may indicate routing, authentication, permissions, or a configuration change. Treat these as investigation clues rather than definitive diagnoses.
If DNS checks fail but the origin appears healthy, compare authoritative records with the records returned by recursive resolvers. Avoid repeatedly changing DNS during an incident without a clear rollback plan. If HTTPS fails while HTTP appears available, focus on certificate renewal, hostname configuration, proxy settings, and the server or CDN TLS configuration.
Not every slow response is an outage. Compare response time with the site’s normal pattern, then check whether the delay affects the whole page or a specific dependency such as an API, database, image host, or third-party script. Performance findings should feed into your website performance and technical SEO checklist, since repeated availability and speed problems can also affect crawling and user experience.
Incident response runbook
- Confirm: Reproduce the failure from a separate connection and capture the URL, timestamp, status code, and visible error.
- Classify: Decide whether the symptom is HTTP, DNS, SSL, application, infrastructure, or regional.
- Check recent changes: Review deployments, DNS edits, certificate changes, plugin updates, and hosting migrations.
- Contain: Roll back a known-bad deployment or disable a failing component only when the action is understood and reversible.
- Escalate: Contact the relevant provider with timestamps, affected URLs, monitoring locations, request IDs, and evidence.
- Communicate: Update internal stakeholders or a status page with what is known, what is being investigated, and when the next update is expected.
- Verify and close: Confirm recovery from multiple locations, test critical user journeys, and continue monitoring for recurrence.
Outage log template
Incident ID: [identifier] Detected: [UTC time] Recovered: [UTC time]
Affected: [URLs, regions, or functions]
Symptoms: [status code, DNS result, SSL warning, or latency]
Checks performed: [locations, tools, provider dashboards]
Actions: [rollback, configuration change, escalation]
Cause or working theory: [confirmed, suspected, or unknown]
Follow-up: [owner, deadline, and preventive change]
When to revisit
Revisit this runbook monthly to test alert delivery and review the outage log. Perform a deeper quarterly review of monitoring frequency, notification limits, escalation contacts, DNS ownership, certificate coverage, hosting capacity, and status-page procedures. Update it immediately after a migration, domain change, CDN or SSL change, major deployment, monitoring-provider change, or significant incident.
Start with a practical 30-minute improvement: add an external HTTPS check, confirm DNS resolution from a second network, enable certificate-expiry reminders, and write down the first three people or providers to contact. Then schedule the monthly alert test and quarterly review. A small site operations habit is easier to maintain than an elaborate plan that nobody consults when the website is down.
