Website Uptime Monitoring That Actually Detects Outages

This page explains how website uptime monitoring actually works, which checks detect real outages and which ones miss them, and how availability is measured and enforced against an SLA. It is written for IT managers, digital leads and agency owners responsible for a website that generates revenue or leads.

A server being up and a website working are different things

Most monitoring tools answer one question: did an HTTP request to the home page return a 200 in under thirty seconds? That question has a green answer in a surprising number of genuine outages.

A WordPress site with a fatal error in a plugin can return 200 with a blank body. A Silverstripe site whose database connection pool is exhausted can serve cached pages from Cloudflare while every form submission fails. A Magento store can render the catalogue perfectly while the payment gateway integration times out at checkout. A Drupal site can be fully available to anonymous visitors and completely broken for logged-in editors. In every case the status page stays green, and the first person to notice is a customer.

Availability monitoring that is worth paying for tests the things the business actually depends on: that the page renders the content it is supposed to render, that a form posts and writes a record, that the checkout reaches the confirmation step, that the API the mobile app calls returns valid JSON. Anything less is a server ping wearing a marketing name.

Check types and what each one can and cannot detect

A monitoring configuration is a set of assertions. Each type catches a different failure class, and the gaps between them are where outages hide.

A reasonable baseline for a lead-generating corporate site is: HTTP plus keyword on the home page and two or three key landing pages, a transaction check on the primary enquiry form, an API check on the CRM integration, certificate monitoring on every hostname, and heartbeats on cron and backups. For ecommerce, add a full checkout transaction check and a search results assertion.

Interval, multi-location confirmation and false alarms

Check interval sets the ceiling on how fast you can possibly know. A five minute interval means a mean detection delay of around two and a half minutes and a worst case of five, before anyone has even looked at the alert. One minute intervals are the practical standard for revenue-critical sites. Thirty second intervals are worth it for checkout paths during peak trading.

The counterweight is noise. A single failed check from a single probe should never page a human. The pattern that works is confirmation: when a probe in Sydney sees a failure, probes in Melbourne, Singapore and somewhere further afield re-test immediately, and the incident only opens if two or more independent locations agree. That single rule removes most false alarms, because the usual causes are local to the probe.

Common sources of false positives worth designing out:

• A WAF or bot management rule challenging the monitoring probe. Allow-list probe IP ranges or use a signed header, and review it after every firewall change.
• Rate limiting triggered by the monitoring itself when intervals are aggressive and check counts are high.
• Transient DNS resolution failures at the probe's resolver rather than at your authoritative nameservers.
• Transaction checks that break because a developer renamed a CSS selector, not because anything is down. Assert on stable attributes, not on styling hooks.
• Timeout thresholds set so tight that a slow but working page counts as an outage. Separate "down" from "degraded" and alert on them differently.

A monitoring system that cries wolf gets muted, and a muted system is worse than no system because it creates the belief that someone is watching.

The failures that break silently

The outages that do real damage are frequently the ones nobody notices for days, because the website looks perfectly fine the whole time. These need explicit instrumentation.

• Cron and scheduled tasks. Silverstripe queued jobs, WordPress WP-Cron, Drupal cron and Laravel schedulers all fail quietly. A heartbeat per critical job, with an expected interval, turns silence into an alert.
• Queue workers. A worker process that dies leaves jobs accumulating. Monitor queue depth and oldest-job age, not just whether the process exists.
• Mail delivery. Enquiry forms that appear to submit successfully while SMTP authentication fails, or while the sending domain's SPF, DKIM and DMARC alignment breaks after a DNS change, are the single most expensive silent failure for lead-generating sites. Monitor send success rate and bounce rate, not just the form's thank-you page.
• Search index. Elasticsearch, Solr or a hosted search service that stops indexing leaves a site returning zero results for everything. Assert that a known query returns a known result.
• Cache and CDN behaviour. A cache that stops being written turns into a full-price origin load test. Monitor hit ratio and origin request volume.
• Disk, inodes and database growth. Log files and session tables fill volumes. Alert at 75 percent, not at 95 percent.
• Backups. A backup job that has been failing for six weeks is only discovered when it is needed. Verify that the artefact exists, that its size is within tolerance, and periodically that it restores.

Certificates, DNS and domain renewal

Certificate expiry is the most avoidable outage there is, and it still happens constantly, usually on a hostname nobody remembered: a legacy redirect domain, a staging environment, a mail subdomain, an API host. Monitor every certificate on every hostname, alert at 30, 14 and 7 days, and alert separately if an automated renewal such as Let's Encrypt has not rotated the certificate within its expected window.

DNS deserves the same treatment. Monitor that authoritative nameservers answer, that critical records resolve to the expected values, and that the domain registration itself is not approaching expiry. Registrar renewal notices go to an inbox that belonged to someone who left. Records get changed during unrelated projects and nobody re-checks the mail records. Watch the values, not just the resolution.

Synthetic checks versus real user monitoring

Synthetic monitoring runs scripted checks from known locations on a schedule. Real user monitoring (RUM) reports what actual visitors experienced, including Core Web Vitals, JavaScript errors and failed requests from their browsers.

You need both. Synthetic checks are what an SLA is measured against, because they are consistent and independent of traffic. RUM is what tells you the enquiry form has been failing for Safari users on iOS for a week while every synthetic check stayed green.

Alert routing and the on-call chain behind the alert

Monitoring is the cheap part. The expensive part is a human who is awake, contactable, authorised and technically capable of fixing the specific application that has broken. This is where most arrangements fall apart: the hosting provider's on-call engineer can restart a server but will not debug a plugin conflict, and the agency that built the site does not monitor anything and reads email at 9am.

A functioning escalation design specifies severity levels with different routing, a primary and secondary on-call engineer, a maximum acknowledgement time before escalation, and a defined authority to act without waiting for client sign-off during a Severity 1. It also specifies who talks to the business while the engineer works, because an incident with no communication feels twice as long. Our guidance on what to do in the first hour of an outage covers the sequence in detail, and break/fix and emergency support covers the arrangement for organisations without an existing retainer.

How uptime is measured and reported against an SLA

An uptime percentage is meaningless until you know what was measured, from where, at what interval, and what was excluded. Before signing anything, get those four answers in writing.

Note what 99.99 percent implies. Four minutes a month is less than the time it takes a human to read an alert and log in, which means the target is only credible with redundancy that fails over automatically. Be suspicious of any provider offering it on a single server.

Also check the exclusions. Scheduled maintenance windows, third-party provider failures, DDoS events and customer-caused incidents are commonly excluded, and some contracts exclude so much that the number is unfalsifiable. Reporting should come from an independent measurement source, list every incident with start time, end time, cause and remediation, and be issued monthly without being requested. If a target has been missed, our page on what to do after an SLA breach sets out the practical options.

Monitoring for infrastructure you already own

Plenty of organisations are contractually or architecturally committed to their own AWS, Azure or Google Cloud account, or to a hosting provider they cannot leave this financial year. That does not prevent an independent monitoring and response arrangement.

In a management-only engagement, the monitoring stack, alerting, escalation and remediation run against infrastructure you continue to own and pay for directly. CloudWatch and Azure Monitor cover the infrastructure layer well and the application layer poorly, so the value added is application-level assertions, heartbeats on background processing, an on-call chain that includes developers who know the CMS, and consolidated reporting across your cloud provider, your CDN and your application. Edge-layer telemetry matters here too, and Cloudflare for enterprise websites covers what the edge can tell you before a request ever reaches origin. Availability monitoring also sits alongside CVE scanning and vulnerability monitoring, because a compromised site and a down site frequently arrive on the same night.

Frequently Asked Questions

What is website uptime monitoring?

Website uptime monitoring is the automated, repeated testing of a website from external locations to detect when it stops working. Effective monitoring goes beyond checking for an HTTP 200 response and includes content assertions, scripted user journeys, API checks, certificate expiry and heartbeats on background jobs. The purpose is to detect a failure before customers do and to produce an independent record of availability.

How often should a website be checked?

One minute intervals are the practical standard for websites that generate revenue or leads, with thirty second intervals on checkout and payment paths during peak trading. Five minute intervals are acceptable for low-stakes sites but add up to five minutes of detection delay before anyone is notified. Whatever the interval, failures should be confirmed from at least two independent geographic locations before an incident is raised.

Why did my monitoring tool say the site was up when it was clearly broken?

Because it was almost certainly only checking the HTTP status code of one URL. A site can return 200 while rendering a blank page, serving cached content from a CDN with a dead origin, failing every form submission, or breaking at checkout. Keyword assertions, transaction checks and API checks are what close that gap.

What does 99.9% uptime actually allow?

A 99.9 percent target allows 43 minutes and 12 seconds of downtime per month, or roughly 8 hours 46 minutes per year. 99.99 percent allows 4 minutes 19 seconds per month, which cannot realistically be met without automatic failover across redundant infrastructure. Always check what the contract excludes from the calculation, because scheduled maintenance and third-party failures are commonly carved out.

Can monitoring be provided if we host on our own AWS or Azure account?

Yes. A management-only arrangement applies monitoring, alerting, escalation and remediation to infrastructure you continue to own and pay for directly. This suits organisations with cloud commitments, internal security requirements or procurement rules that prevent moving hosting.

What is the difference between monitoring and an SLA?

Monitoring detects a problem and sends an alert. An SLA is the contractual commitment that a named party will acknowledge that alert within a defined time, begin work within a defined time, and be accountable if they do not. Monitoring without a response obligation just documents your outages more precisely.

Managed uptime monitoring and response from UnDigital

An alert is only worth as much as the person obliged to answer it. UnDigital operates monitoring and the engineering team that acts on it, which means the same organisation that detects a fatal error in a Silverstripe module or a failing WordPress cron is also the one that fixes it, with no gap between the infrastructure vendor and the development vendor for the problem to fall into.

Monitoring is configured per site rather than from a template: the pages, journeys, endpoints, jobs and certificates that matter to your business, with response times and escalation paths set out in a website support SLA and reported monthly. It is available as part of managed hosting or as a management-only engagement on infrastructure you already own. Every engagement starts with an audit of what is currently being monitored, which almost always finds something important that is not.