A single monitor sends a request to your site on a schedule. If that request fails, you get a message. The trouble is that the failure may have happened on the way to your site, not at the site itself. A network path can be broken for a few minutes, a provider can drop packets, or one route can be slow. From where the check runs, your site looks down. From most other places, it is fine.
This post covers how to tell the two apart, and how to set up your monitors so that a blip does not turn into a midnight call.
The problem: one check from one place can fail for reasons that are not your site
When you have one monitor and it fails, you have one fact: the check did not get a good response. You do not yet know whether the site is down for everyone, down for some visitors, or fine and unreachable from one network.
That gap matters. If you act on every single failure, you will spend time looking at a healthy site. If you ignore every single failure, you will miss the one that is real. A second opinion from a different place helps you tell these cases apart.
Typical false alarms: a routing problem, a brief timeout, a slow DNS lookup
Most false alarms fall into three groups.
The first is a routing problem. Traffic between the monitor and your host takes a path that is congested or broken for a short time. The site is up, but the request never arrives. These usually clear within minutes, and they rarely affect every network at once.
The second is a brief timeout. Your site answers, but a little later than your timeout allows. A cold cache, a busy database, or a backup running in the background can push one response over the limit. If the timeout is very short, a healthy site will look broken.
The third is a slow DNS lookup. Before any request reaches your server, the name has to resolve to an address. If the resolver is slow or returns an error for a moment, the check fails before your web server has even been asked. Your site may be entirely fine.
None of these is your site going down. All of them produce the same alert.
What a second location check does: confirms the failure from a different place before you are woken up
A second location check runs the same request from another place. When the first check fails, the second one is the test of whether the failure is general or local to one path.
If both checks fail, the problem is probably real and you should act. If only one fails, the problem is probably on the path between that location and your host, and you can wait to see whether it clears.
AperioFlow runs checks from the UK and hosts its own service in France. Use a second location check to get a second view of the same URL. It does not replace your own testing, and it does not tell you why a failure happened. It tells you whether the failure is worth acting on right now.
How to decide what to alert on: failures confirmed twice, a short retry, a sensible timeout
Three settings do most of the work.
First, decide on confirmation. Alert only when a failure is confirmed twice in a row, either by a retry from the same place or by a check from the second location. A single failure is a question. Two failures in a short window is a signal.
Second, set a short retry. A retry a few seconds to a minute after the first failure catches many routing blips. If the retry succeeds, you have lost nothing but a few seconds of checking.
Third, set a sensible timeout. A timeout that is too short creates false alarms on a healthy site under load. A timeout that is too long hides a site that has stopped answering. Pick a value that matches how long your slowest normal page takes to respond, with some room to spare, and adjust it after you see a few weeks of results.
Write these choices down. When you come back to the monitor in six months, you will want to know why it is set the way it is.
What to do when only one location fails: look at DNS, the host and recent changes
When only one location fails and the others pass, work through a short list before you do anything else.
Start with DNS. Check that the name resolves to the address you expect, and check the time to resolve. A slow or changed record is a common cause of a failure that only some places see.
Next, look at the host. Check whether your hosting provider has a status notice, and whether your server is reachable from outside. A host that is having trouble in one region can look like a site outage from a single location.
Then look at recent changes. Did someone deploy, change a firewall rule, rotate a certificate, or update a DNS record in the last day? A change that only affects some paths is easy to miss.
If the failure from that one location clears by itself and the others stayed healthy, note it, and watch whether it happens again. A pattern of single-location failures often points to a network path rather than your code.
Keeping the alert useful: one message to the right person, with the monitor name and the time of the first failure
An alert is only useful if the person who receives it can act on it quickly. Keep the message short and specific. It should name the monitor, say which location or locations failed, and give the time of the first failure, not just the time of the latest check.
Send it to one person who is responsible for that site, or to a small group inside your organisation. Alert emails go only to people in your organisation, so you can decide who is on the list. If a client site has its own contact, route the alert to your team first, then decide what to pass on.
Do not send the same alert to everyone. A flood of messages teaches people to ignore them.
Pair it with a status page so customers hear from you first
Even with good alerts, a real outage will reach your customers somehow. The question is whether they hear it from you or from a support ticket.
AperioFlow includes a status page you can keep up to date during an incident. Post a short note as soon as you have confirmed a failure from two places, then update it when you know more. Customers do not need a full analysis. They need to know that you know, and roughly when you expect an update.
When the incident is over, post a short closing note. Keep it factual.
Set up your first monitor on the free plan and add a second location check
If you are new to this, start small. The free plan includes 10 monitors, so you can cover your main site, a couple of key pages and a background job without paying anything.
Add your site as a website monitor. Set a short retry, a timeout that suits your normal response time, and a second location check. Leave the alert going to one person for the first week, then review how often it fired and whether each alert was worth acting on.
Start free at https://app.aperioflow.co.uk/#/signup and add your first website monitor in a few minutes. Then add the second location check once the first one is working as you expect.