The check interval is the gap between one check and the next. It decides how long a site can be down before anyone hears about it. If the monitor checks every few minutes, the longest silence is roughly that gap, plus the time the alert takes to reach you. If it checks every half hour, the silence can stretch to half an hour before the first check even runs.
That is the reason to think about the interval before you think about anything else. A shorter interval does not make a site more reliable. It only shortens the time between a failure and your knowing about it.
Why the interval matters
Most small sites fail in ways that matter to someone, and the cost of finding out late depends on what the site does. A missed hour on a brochure site is an embarrassment. A missed hour on a checkout is lost orders. Start from the cost of silence, then choose the interval.
Every HTTPS monitor also checks the site's certificate and warns you at 30, 14 and 7 days before it expires, so an expired certificate should not catch you out.
A short rule of thumb
For a shop or an app where people sign in, book or pay, use the shortest interval you can justify. These are the sites where a few minutes of failure costs real money or real trust, and where you want to hear about it before a customer writes in.
For a brochure site, a longer interval is usually fine. Visitors arrive in ones and twos, the content changes rarely, and a gap of several minutes seldom costs anything you could measure. You still want to know when it goes down. You just do not need to know within the minute.
For a client site you only look after, the question is less about speed and more about who gets the message. A client may not be watching their inbox, so the interval should match how quickly you can act on an alert, not how quickly the site could fail. If you cannot respond within the hour, checking every minute only fills your inbox sooner.
Check interval versus the number of failed checks before an alert
The interval is only half of the picture. The other half is how many failed checks have to happen before you are alerted. A single failed check can be a real outage, or it can be a network blip between the checker and your site. Waiting for a second or third failure filters out most of the blips, but it also adds time to every real alert.
The two settings work together. The total time before an alert is roughly the interval multiplied by the number of failed checks you require. A short interval with a high failure count can take about as long to alert as a longer interval with a low count. The real question is how long you can accept, and then how you split that time between the interval and the failure count.
If you find yourself shortening the interval to get faster alerts, check the failure count first. It is often the setting that is making the alerts slow.
Why a second location check helps more than a shorter interval
When alerts look flaky, the cause is often the path between the checker and your site, not the site itself. A shorter interval will not fix that. It will only produce more false alarms, faster.
A check from a second location tells you whether the problem is local to one route. If both locations fail, the site is probably down. If only one fails, look at the network path, not the server. We cover this in more detail in our post on second-location checks.
A worked example: five monitors for a small team
Suppose a team of four runs an online shop, a client's marketing site, a client's staging site, a public API and a nightly backup job. Here is how each might be set up. The exact intervals on offer are on the pricing page and in the docs, so choose from those when you set them up.
- The online shop, checkout page. Frequent checks, because a failed checkout loses sales straight away. Alert on the first confirmed failure with the second-location check on.
- The public API. Frequent checks, because other people's software depends on it and they will report problems quickly if you do not.
- The client's marketing site. A longer interval, because it changes rarely and visitors are not waiting on a transaction. The alert goes to the person who looks after the client.
- The client's staging site. A longer interval and alerts to a small group only. Nobody outside the team uses it, so a slower response is acceptable.
- The nightly backup job. Use a heartbeat monitor rather than a web check. The job pings the monitor when it finishes. Set the window to the job's schedule plus some slack, so a missed run raises an alert the next morning rather than sitting unnoticed for a week.
Notice that the interval is only one choice in each case. The reason behind it, and the alert rule that goes with it, matter as much.
What to do after the first week
After about a week, open the alert history for each monitor and read it. Ask three questions. How many of the alerts were real? How long did each real outage last? Which alerts were noise, and what caused them?
If a monitor produced several alerts that cleared within a minute, the interval or failure count may be too sensitive, or the second-location check may need to be on. If a real outage was caught late, shorten the interval or lower the failure count for that site only. Change one setting at a time, then look at the history again after another week.
Start with the free plan and try two intervals
The free plan includes 10 monitors, which is enough to test this properly. Pick one site that matters to you. Create one monitor on it at a shorter interval, and a second monitor on the same address at a longer one. After a few days, compare the alerts each one raised and how quickly it caught the outages you saw.
Start free at https://app.aperioflow.co.uk/#/signup. Create a monitor on your busiest site and set the interval after reading this post. You will learn more from one week of your own alert history than from any rule of thumb.