Uptime Check Cadence: Matching Probe Frequency to Business Impact
Most small site teams set up an uptime check once and then forget about it. The check runs every few minutes, sends an email when it fails, and eventually someone starts ignoring the messages. The problem is rarely that monitoring exists. The problem is that the cadence, thresholds, and retry rules were never chosen on purpose. This article takes a different angle: treating probe frequency as a deliberate decision tied to what a failure costs you, and walking through how to set it so that alerts stay meaningful. The advice here is general practice and does not depend on any particular hosting plan or provider feature. Check your own requirements against whatever tooling you use.
Start With the Cost of Silence
Before choosing a probe interval, ask a simple question: how long can this site be broken before someone notices, and what does each hour of that cost? A brochure site for a local business may lose little if it is down for two hours on a Sunday. A site that takes bookings or sells products loses revenue and trust with every minute, and it may matter more that a failed checkout is caught quickly than that the homepage is up.
Write down the answer for each important page or function. Mark the ones where silence is expensive. Those get the tightest cadence and the most direct alert route. Everything else can be checked less often without much harm. This prevents the common pattern of checking the homepage every minute while the contact form has been broken for three days.
A useful exercise is to list the three ways your site would most embarrass you if it failed quietly: a payment that did not complete, a lead form that stopped saving submissions, or a login page that returned errors. Those become your priority probes, regardless of how important the homepage looks.
Choosing an Interval Without Creating Noise
Shorter intervals detect outages faster, but they also multiply the chances of false alarms. A single network hiccup that lasts thirty seconds can trigger a failure on a check that runs every thirty seconds, while the same hiccup would pass unnoticed on a check that runs every five minutes. Interval and retry logic must be considered together.
A reasonable approach for many small teams is to use a moderate interval for broad coverage, such as every few minutes, and a shorter interval only for the high-cost paths identified earlier. Then add a confirmation step: an alert fires only after two or three consecutive failures from the same location. This converts a flicker into a non-event while still catching a sustained outage within a few minutes.
Record how many alerts each rule produces over a couple of weeks. If the number of alerts is high and almost none correspond to real problems, the interval or retry count is too aggressive. If real outages were noticed by customers before any alert fired, the rule is too lenient. Adjust in small steps and keep notes on what changed.
Thresholds Beyond Up and Down
A binary up-or-down check misses a common failure: the site responds, but slowly enough that visitors give up. Response time thresholds add a useful signal. Pick a threshold based on what your pages normally do, not an arbitrary number. Measure a baseline over several days, note the typical range, and set a warning level somewhat above the normal ceiling. A sustained climb in response time often precedes a full failure, giving you time to act.
Also check the content of responses where practical. A page can return a successful status code while displaying an error message, an empty template, or a maintenance notice. Matching a known string on the page, such as a heading or a footer phrase, catches these cases. Keep the expected string simple and stable so that routine copy edits do not cause false failures.
A Practical Cadence Checklist
Use the following plain checklist when setting or reviewing your probes. First, list every page or function where failure is costly, and rank them. Second, assign the tightest interval to the top tier and a moderate interval to the rest. Third, require two or three consecutive failures before alerting, and confirm that the retry window is shorter than your tolerance for silence. Fourth, set a response time warning based on a measured baseline rather than a guess. Fifth, add a content match for at least the top-tier pages. Sixth, decide who receives each alert and at what hour, and avoid sending every warning to every person. Seventh, review alert history monthly and note any missed outage or excessive noise.
Finally, document the rules in a short note that lives alongside your other operational records. When a team member changes, the next person should be able to read why the cadence is what it is, instead of guessing and either silencing the checks or multiplying them. Monitoring that is understood and maintained will serve a small team far better than an aggressive setup that everyone has learned to ignore.