What should trigger a down alert
Start with failures that visitors would experience directly: the homepage does not respond, the login or checkout path returns an error, the API endpoint another system depends on fails, DNS no longer resolves, or the TLS certificate is invalid or close enough to expiry that it needs action.
Avoid alerting on every single failed request. A single network blip from one probe location can be noise. For most sites, a better rule is two or three consecutive failures, preferably confirmed from more than one probe location, before opening an incident.
Who should get the alert first
Route the first alert to whoever can actually start the fix: the founder, the freelancer on maintenance, the agency support channel, or the engineer on call. A shared inbox or Slack channel is fine only if someone is responsible for watching it.
If no one owns the destination, the alert does not exist in practice. The site still gets discovered by a customer first; the monitoring tool just creates a timestamped record that nobody saw.
A practical retry and escalation timeline
For a normal customer-facing site, check every 5 minutes, require a small consecutive-failure threshold, and alert immediately after that threshold is crossed. That catches real downtime within a predictable window without paging someone for every transient network failure.
Escalation should match business risk. A brochure site might notify email first. A checkout flow, paid API, or client site under maintenance contract should go to a faster channel like Slack, Discord, or a webhook into the system the team already watches.
Alert copy that speeds response
A useful alert says what failed, where it was checked from, when it started, and what the monitor expected to see. "Homepage returned 500 for two consecutive checks" is actionable. "Website issue detected" is not.
Include enough context to skip the first round of guessing: URL, status code, response time, TLS or DNS failure, and a link to the incident history. During an outage, clarity matters more than clever wording.
How to reduce false positives
Use consecutive failures, probe locations, and sane response-time thresholds. Do not set a response-time alert so low that normal variance becomes an incident. Do not monitor a page that is expected to block bots, require a session, or vary wildly by visitor unless you have a clear assertion for what "healthy" means.
Review the first few incidents. If every alert is noise, adjust thresholds before people learn to mute the channel. If alerts arrive after customers complain, shorten the interval or route the alert somewhere more visible.
How Holter handles down alerts
Holter watches URLs, TLS, DNS, domain expiry, and heartbeat check-ins from outside your infrastructure. You choose the alert channel and the failure threshold, so a real incident opens only after the monitor has enough evidence to be worth your attention.
The free plan covers 5 monitors with 5-minute checks and no credit card, enough to put trusted down alerts on a real site: homepage, login or API, TLS, domain, and one heartbeat for the background job users never see.
Holter watches this for you: outside-in monitors plus dead-man heartbeats for silent failures. Free plan: 5 monitors, 5-minute checks, no credit card.
Create a trusted down alert — free