Every monitoring setup eventually gets tuned, and every tuning session starts with the same two dials: how often do we check, and how bad does it have to look before we get told. Get those right and monitoring feels like a calm colleague who taps you on the shoulder when something actually matters. Get them wrong and it’s a smoke alarm going off every time you make toast — which you’ll eventually silence, and then it can’t tell you about the fire either.
Here’s how we think about both dials in HITS Scout, and the settings we’d recommend for the common cases.
Check intervals: the trade-off nobody escapes
HITS Scout supports per-monitor check intervals from 30 seconds to 24 hours. The interval you pick buys you detection speed and spends site checks and alert noise. The honest math on detection: with a 30-second interval, your average time-to-detection for a hard outage is 15 seconds; with 5 minutes, it’s two and a half minutes. Both numbers are fine for most things — the question is what actually needs sub-minute detection.
Our recommendations after running these combinations in production:
- Revenue path (checkout, API, customer login): 30 seconds. This is what the Enterprise interval is for. If this tier of thing goes down, every minute has a dollar figure attached.
- Primary websites and apps: 1 minute. The Pro default. Fast enough that an outage is caught before most visitors notice, slow enough that a single dropped packet doesn’t page anyone.
- Marketing sites, blogs, docs: 5 minutes. The free-tier interval. For content sites, five minutes of downtime is a rounding error; the link crawler and slow-response tracking do more useful work here than raw speed.
- Archival and low-stakes properties: hourly or slower. If a site’s job is to exist rather than to be up-to-the-second, a 24-hour check confirms it’s still alive without wasting anyone’s attention.
Thresholds: how bad before it’s bad
The second dial is what counts as a failure worth knowing about. HITS Scout’s alerting is threshold-based and configurable per monitor, and it has one piece of built-in intelligence that saves a remarkable amount of noise: before alerting on link-check failures, it verifies your primary URL.
The logic is simple and effective. If deep links are failing but the primary URL is healthy, you have a link problem — report it, but it’s not an outage. If the primary URL is failing too, the whole site is down — that’s one clear alert, not forty confused ones. This distinction alone eliminates most of the 3am false-positive pages that make people distrust their monitors.
Slow-response thresholds work the same way: pick a response-time ceiling that’s realistic for the site. A WordPress blog on shared hosting has no business alerting at 500ms — set the threshold at a level where an alert genuinely means degradation, like 3–5 seconds. The goal is that when your phone buzzes, your first reaction is “this is real”, not “probably nothing again”.
Consecutive-failure counts: the persistence tax
Most transient failures are exactly that — transient. A BGP reconvergence, a container restart, a burst of traffic that clears in ninety seconds. Alerting on the first failed check means alerting on all of these. Requiring two or three consecutive failures before alerting filters the majority of blips at the cost of one or two extra intervals of detection time. Our default recommendation: require 2 consecutive failures for 1-minute monitors, 1 for 30-second monitors — the faster interval already amortises the blips, and on the slow tiers the extra wait isn’t worth it.
A worked example
Here’s the setup we’d suggest for a typical small-business stack, roughly $13/month of HITS Scout:
- Customer-facing app (Enterprise, 30s): strict thresholds, alert immediately after 2 consecutive failures. This is the one that can wake you up.
- Main website (Pro, 1m): moderate thresholds, alerts to the team channel rather than on-call.
- Docs site, blog, staging (Free, 5m): lenient thresholds — these can wait for morning.
That’s eight monitors across three tiers, each tuned so that alert volume correlates with actual importance. The whole point of a monitoring stack is to convert site problems into informed action — and the tuning stage is where you decide whether “informed” is true.
Every plan has per-monitor interval and threshold configuration, so you can build this exact structure starting on the free tier: hitsscout.link/signup.
Next in this series: getting those alerts into Discord and Slack, and structuring channels so the right people see the right problems.