A page that takes eight seconds to load can feel broken to a customer, even when the server is up and every status check passes. The problem is real, but it needs a different response from an outage. If you send the same alert for both, people learn to ignore the alert.
This post covers how to choose a response time to alert on, and how to keep that alert from becoming noise.
Why a slow site feels like a broken one
Most visitors do not know the difference between a site that is down and a site that is slow. They see a blank screen or a spinner that does not stop, and they leave. For them, both mean the same thing.
For you, the difference matters. A down site usually needs someone to act now. A slow site may need someone to look at it today, or this week. If your alerts treat both as emergencies, the team will start to mute the channel, and the next real outage will sit unread.
So the first decision is not the number. It is whether a slow page deserves to wake anyone at all.
Measure normal first: a week of typical response times
You cannot pick a sensible threshold without knowing what normal looks like for your site. A marketing page, a logged-in dashboard and a checkout step can each have very different typical times. Guessing a figure from a laptop on your office connection tells you little about what a customer on a phone in a busy train station will see.
For one week, let your monitoring run and note how long your important pages take to respond. Look at the spread, not just the average. Most sites have a fairly tight band of typical times, with the odd slow check at busy hours or during a backup. Write down the usual range and the occasional peak.
If your monitoring tool does not show how long each check took, you will need to find that out before you begin. Do not assume it does. Start with the pages that matter most to customers, and leave the rest until you have a baseline you trust.
Pick a threshold that is clearly outside normal
Once you know the usual range, set the threshold somewhere clearly beyond it. If your pages normally respond in under one second and occasionally reach two during peak hours, a threshold of two seconds will fire every afternoon. That is not a warning. It is a fact about your traffic.
A sensible starting point is a value well above your typical peak, so that an alert means something has changed. The exact figure depends on the page and on what your customers expect from it. A checkout step may deserve a tighter limit than a help article. Write the reason next to each threshold, so that the next person to look at it understands the choice.
Do not treat the threshold as permanent. It is a first guess, and you will adjust it once you have seen how it behaves.
Ask for more than one slow check in a row before alerting
A single slow response is often nothing. A cache was cold, a database query ran long, or a network hop was busy for a moment. If every slow check sends a message, the alert channel fills with false alarms.
Ask for more than one slow check in a row before anyone is told. Two or three consecutive slow results point to a pattern, which is worth a look. One slow result on its own usually is not. The number you choose depends on how often your checks run. If checks run every few minutes, three in a row covers a short window of real slowness. If you check less often, you may need a longer run to see the same thing.
Keep the rule simple enough that you can explain it in one sentence. If nobody on the team can say what triggers the alert, nobody will trust it.
Separate slow-page alerts from outage alerts
An outage and a slow page need different routes. An outage means a check fails outright, such as a timeout or an error response. That should reach the people who can fix it, quickly and in a form they can act on. A slow page is a warning. It can go to a quieter place, or be reviewed at the start of the working day.
Keep them separate in your head and, where your tool allows, in your settings. Give each one its own name, so that a message tells the reader what kind of problem it is before they open it. Alert emails go only to people in your organisation, which is worth remembering when you decide who should receive which warning.
If you run a status page for customers, think carefully about what you show them. A slow page is not always worth a public incident. An outage usually is. Decide that rule before the next incident, not during it.
Review the threshold after each change to the app
A threshold set in March may be wrong by June. You add a feature that loads more data, you move hosting, or you change how images are served. Each change can shift the normal range, sometimes upwards and sometimes down.
After any change that affects the pages you monitor, look at the response times for a few days. Compare them with your baseline. If the normal range has moved, move the threshold with it. If a new slow spot has appeared, decide whether it needs a fix or just a note.
Make this a short habit rather than an occasional project. A quick check after each release costs little and stops the alerts drifting out of step with the site they describe.
To put this into practice, start free at https://app.aperioflow.co.uk/#/signup, let your status checks run for a week, and look at what your site does when nobody is watching it. The free plan includes 10 monitors, which is enough to cover your most important pages while you find your normal.