Uptime monitoring that catches real problems without alert fatigue

Uptime monitoring looks like a solved problem. Sign up for a service, enter your URL, and get an email when the site goes down. In practice, the setups we inherit tend to fail in one of two ways. Either they check only the home page and miss the outage that actually matters, such as a broken checkout or an expired certificate on the API, or they alert on every transient blip until the team mutes the channel. Both end the same way: customers notice the problem before you do. This is how we design monitoring for the sites and applications in our care.

Monitor what customers actually do

A home page returning HTTP 200 tells you the web server is running. It does not tell you the site works. We define checks around the journeys that matter to the business, typically three to eight per site:

• Availability of key pages, checked for expected content rather than just a status code. A page that returns 200 with a database error message is down.
• Critical transactions such as login, search, add to cart and form submission, run as synthetic checks every five to fifteen minutes.
• APIs and webhooks that mobile apps, partners or internal systems depend on.
• Certificates and domains, with warnings 21 days before expiry and again at 7 days.
• Background jobs such as order sync, email queues and backups, using heartbeat checks that alert when a job fails to check in.
• Third-party dependencies like payment and shipping providers, so you can tell whether an outage is yours.

Heartbeat monitoring deserves special mention. Many of the costliest incidents we have seen were silent: an inventory sync that stopped for three days, or a backup job that had not run in weeks. Nothing was down, so nothing alerted.

Set thresholds that filter noise

Networks are imperfect, and a single failed request from one location is usually noise. Our defaults:

1. Check from at least three regions and alert only when two or more agree the site is failing.
2. Require consecutive failures, typically two checks in a row, before declaring an incident. At a one-minute interval, that adds about a minute to detection time and removes most false alarms.
3. Use sensible timeouts. A 30-second page load is effectively an outage for users, so we alert on response time too, with a threshold set well above normal but below frustration, often 5 to 8 seconds for full page responses.
4. Separate warnings from pages. Slow responses, certificate warnings and elevated error rates go to a chat channel. Only customer-facing outages wake someone up.

An alert should mean someone needs to act now. If the right response to an alert is to wait and see, it should not be an alert.

Route alerts to people who can fix them

Detection is only half the job. An alert sent to a shared inbox at 2 a.m. is not monitoring. We define an escalation path for every site:

• A primary on-call engineer who receives the page through a phone app with acknowledgment.
• A secondary who is paged automatically if the primary does not acknowledge within 10 to 15 minutes.
• A named contact on the client side for decisions only they can make, such as whether to take a store offline.

Each alert links to a short runbook: what the check does, the most common causes, and the first three things to try. On a mature site, most runbook entries start with "check the status of the hosting provider and the CDN," because a surprising share of incidents are upstream.

Maintenance windows and planned work

Planned deployments and host maintenance are a common source of false pages. We schedule maintenance windows in the monitoring tool so that expected downtime is silenced for the affected checks only, and we make sure each window has an end time. An open-ended silence that nobody remembers to lift is how a real outage goes unnoticed for a weekend.

Communicate during incidents

For sites with customers or partners who depend on uptime, a status page reduces support volume considerably during incidents. It does not need to be elaborate: current status per component, a short incident history and the ability to subscribe to updates. The discipline is in updating it promptly. We aim to post an initial notice within 15 minutes of confirming an incident, even if all it says is that we are investigating.

Afterward, every customer-facing incident gets a brief written review covering the timeline, the cause, the time to detect and the time to resolve, and one or two changes to prevent a repeat. The review often improves the monitoring itself, for example by adding the check that would have caught the problem earlier.

Review monitoring monthly

Monitoring decays as the site changes. New features launch without checks, old checks target pages that no longer exist, and thresholds drift out of line with real performance. A monthly review of about 30 minutes keeps it honest:

• Which alerts fired, and were they all actionable?
• Were there incidents that monitoring missed or caught late?
• Have any new critical journeys launched without a check?
• Is on-call coverage accurate for the coming month?

On the sites we manage, this review typically keeps actionable alerts above 90 percent, which is the level at which people keep trusting them.

Our uptime monitoring service sets up these checks, thresholds and escalation paths, and connects them to our on-call rotation. For deeper visibility into application errors and performance, it pairs well with the observability work in our managed cloud hosting, and all of it is included in our monthly care plans.

Find out about outages before your customers do

Tell us which journeys matter most on your site and we will propose a monitoring setup with a fixed monthly price. Get in touch for a quote.