Uptime Check Baselines: Measuring Normal Before You Alert on Abnormal
Most uptime alerts are written before anyone knows what healthy looks like. A threshold of two seconds sounds reasonable until a page that normally loads in four hundred milliseconds starts alerting every evening because the threshold was never tied to real measurements. A baseline fixes this. It is a recorded picture of how your site behaves when it is working, gathered over enough days to show daily and weekly rhythms. Once you have it, you can decide what counts as a meaningful deviation. This article walks through a practical method for building that baseline, choosing thresholds from it, and reviewing it over time. The method applies whatever monitoring tool you use, and it does not depend on any particular provider's features. The goal is to replace assumptions with records that your team can inspect and explain.
Define what you are measuring before you measure it
A baseline is only useful if the measurement behind it is consistent. Start by listing the specific URLs and actions you care about. For a small business site, that usually includes the homepage, the main contact or booking form, any login page, and the checkout or inquiry path if one exists. Each of these should be a separate measurement target, because a homepage that responds quickly tells you little about whether the form beneath it still submits.
For each target, write down three things: the expected HTTP status, the content that proves the page rendered correctly, and the maximum time you would accept before a human should look at it. The content check matters more than most teams expect. A server can return status 200 while serving an error template, a maintenance banner, or an empty shell. Choose a short string that appears only on the real page, such as a heading or a footer phrase that rarely changes, and make the check fail if it is absent.
Collect samples long enough to show rhythm
A single afternoon of readings cannot tell you what normal is. Response times usually vary with time of day, with traffic from your audience, and with scheduled jobs such as backups, cache rebuilds, or email batches that run on the same host. A useful baseline covers at least two full weeks, so that you see each weekday at least twice. If your traffic is seasonal, note the period you sampled so that later comparisons are honest about the context.
Record the raw values, not just averages. For each target, keep the median, the 95th percentile, and the maximum observed response time, along with the count of failed checks. Averages hide spikes, and a few very slow responses can be the earliest sign of a problem. Store these figures in a simple spreadsheet or document with the date range, the probe settings, and the location the checks ran from. If you later change the probe interval or move the checks to another region, the baseline may no longer be comparable, and you should note that change.
Turn the baseline into thresholds
With a baseline in hand, thresholds become a matter of arithmetic and judgment rather than guessing. A common approach is to set a warning level somewhat above the 95th percentile, and a critical level well above the maximum normal reading, with the exact margins chosen by the team. For example, if the homepage's 95th percentile is 900 milliseconds, a warning at 1.5 seconds gives room for ordinary variation while still catching a real slowdown. The numbers themselves are less important than the fact that each one can be traced back to recorded evidence.
Keep two kinds of alerts separate. Availability alerts fire when a check fails outright: the page does not respond, returns an error status, or misses its content string. Performance alerts fire when a response is slow but still correct. Route them differently. A failed login check may need immediate attention, while a slow blog post may only need a note in the next review. Mixing them trains people to ignore the channel.
A checklist for building and maintaining your baseline
Use the following questions as a working checklist. First, have you named each target and its expected status code and content marker? Second, have you collected at least fourteen days of readings across all weekdays? Third, have you recorded the median, 95th percentile, and maximum for each target? Fourth, have you documented the probe location, interval, and date range so the numbers can be reproduced? Fifth, have you set separate warning and critical thresholds and tied each one to a specific figure in the baseline? Sixth, have you decided which alert type goes to which person or channel?
Finally, schedule a review. Once a quarter, or after any significant change such as a redesign, a plugin update, or a hosting plan change, compare recent readings against the stored baseline. If normal behavior has shifted, update the baseline deliberately and record why. A baseline that is never revisited slowly becomes fiction, and alerts built on fiction either wake people for nothing or stay silent when something is wrong. Treat the baseline as a living record, and your alerts will stay tied to what your site actually does.