I'm building a lightweight uptime monitor that checks a URL every few minutes and marks it down when a request fails. The problem is that one slow response, CDN hiccup, or regional network issue can trigger a false alert even though the site recovers a few seconds later.
So far I've tried retrying two or three times before alerting, but that delays genuine outage notifications. Monitoring from one region keeps costs low, though it can mistake a local connectivity problem for a site-wide outage. I'm considering multi-region checks and only declaring an outage when multiple locations agree, but that may be too expensive for a small free tier.
For a monitor aimed mostly at small sites and side projects, is smart retry logic with backoff usually enough, or is checking through multiple independent locations worth the extra cost? Would you use different detection rules for free and paid plans, or keep the sensitivity consistent?
4 Answers
Retrying through the same monitoring server and network path does not eliminate every false positive. If the connection between your checker and the target is broken, all of those retries can fail even while the site is healthy. A cheaper alternative to full multi-region infrastructure is to perform the follow-up check through a different relay or proxy. For example, check through one connection first, then confirm the failure through another independent connection before sending an outage alert. That gives you a stronger signal without requiring a large monitoring fleet.
A successful HTTP response does not always mean the application is healthy. Add an optional content check for a stable piece of expected text, or check for known error markers. That can catch cases such as an application returning a friendly-looking 200 response while displaying a database connection error. It also gives customers more control over what “healthy” means, although the check should be configurable because page content can change.
Instead of treating every check as a binary up-or-down result, maintain a rolling reliability score. Track recent pass rate, total uptime, current and longest successful streaks, and the number of checks collected. Smooth the score so a target with only a few successful checks cannot immediately look more reliable than one with a long history. This gives you a more useful view of stability, though it works better for reporting and alert confidence than for instant outage detection.
That solves a different problem than retries, but it’s useful for distinguishing a genuinely unreliable service from a newly added target. I’d probably combine the score with a simple alert threshold.
For a small number of fairly stable sites, two or three retries are often enough. A practical setup is to retry with a short delay and only notify after the final failed attempt. That keeps the implementation cheap and avoids most one-off false positives, although the alert may arrive a little later.
That matches what I’m leaning toward for the basic tier: accept a small detection delay in exchange for fewer noisy alerts.
The independent-path distinction is the part I was missing. I may keep same-path retries on the free tier and use a second connection for paid plans, since proxy bandwidth would add a real cost.