Every monitoring tool has to answer one awkward question: how sure are you that the thing is down? Answer too fast and you page a sleeping engineer because a load balancer dropped a single TCP connection. Answer too slowly and your customers find the outage before you do.
relay19 answers it with a consecutive failure threshold. A check that comes back wrong does not open an incident on its own. It has to come back wrong several times in a row, three by default, before anyone is told.
What a single failed check really means
Probes run over the public internet, which is a hostile place to measure anything. In a normal week, an endpoint that never actually goes down will still hand you failures like these:
- A TLS handshake that times out because a router somewhere reset a session.
- A
502served during the two seconds a container took to restart on deploy. - A DNS resolver that returned
SERVFAILonce and answered correctly on the retry. - Packet loss on one transit path that clears itself in under a minute.
None of those are worth a phone call at 3am. All of them look identical to a real outage if you only ever look at one sample.
The arithmetic of waiting
Waiting is not free, and it is worth being precise about the price. With a
check interval of i and a threshold of n consecutive failures, the worst
case time from the first broken request to an alert is:
detection = i x nFor a 60 second check with a threshold of 3, that is three minutes. Drop to 30 second checks and the same threshold detects in ninety seconds. Raise the threshold to 5 on a 60 second check and you are at five minutes, which for a checkout endpoint is a long time to be quiet.
How low the interval can go is a plan question. The free plan checks every 5 minutes, so three misses there is fifteen minutes; paid plans go down to 30 seconds, and 15 on the larger ones.
This is the real tradeoff, and it is the reason relay19 exposes both numbers per monitor rather than picking one for you. Interval buys you resolution. Threshold buys you confidence. You pay for both in detection time.
Sensible defaults, per monitor
The defaults are three misses on a one minute interval, because that combination almost never pages on noise and still detects inside a coffee break. From there it is worth splitting your monitors into three groups.
Front door. The pages and APIs a customer touches. Short interval, low threshold. A 30 second check with a threshold of 2 detects in a minute and still ignores a lone blip.
Supporting services. Internal APIs, queues, admin panels. The default is fine. Nobody needs to know within sixty seconds that the internal metrics dashboard is having a moment.
Flappy by nature. Endpoints behind a cold-starting serverless platform, or anything that legitimately returns errors under normal load. Raise the threshold to 4 or 5 and accept the slower detection. If you find yourself raising it past 5, the endpoint is telling you something a monitor cannot fix.
Recovery works the other way
Opening an incident is deliberately slow. Closing it is deliberately fast: the first passing check resolves the incident and sends the recovery notification. There is no acknowledgement step and no waiting for a second opinion.
That asymmetry is on purpose. A false alarm costs you an interruption. A false recovery costs you nothing, because if the service is still broken the next failing checks simply open a new incident. Being eager to say “it is back” is cheap; being eager to say “it is down” is not.
Every miss is still recorded
Not paging is not the same as not knowing. Failures that never reach the threshold are still stored as check results, so a monitor that quietly misses one check in every twenty shows up in the response history even though it never opened an incident. That pattern is usually the interesting one. A hard outage announces itself. A slow degradation only shows up if something has been counting all along.
If you want to see this on your own endpoints, the quickstart has you running your first check in about a minute, and the free plan covers ten monitors with no card.