Check intervals and thresholds
Two settings on every monitor decide how quickly UpAll notices trouble and how sure it is before raising the alarm: Check every, the interval between probes (1 to 5 minutes, default 1), and Failures before incident, how many consecutive checks must fail before an incident opens (1 to 10, default 3).
How they combine into detection time
A probe runs once per interval. The first failure starts a streak; if the streak reaches the configured count without a single success, an incident opens and every active staff member in the workspace is emailed — see how incidents open and close. One successful check resets the streak to zero.
Detection time is therefore roughly interval × failures:
| Check every | Failures before incident | Alarm raised after roughly |
|---|---|---|
| 1 min | 1 | 1 minute |
| 1 min | 3 (default) | 3 minutes |
| 1 min | 10 | 10 minutes |
| 5 min | 3 | 15 minutes |
| 5 min | 10 | 50 minutes |
One detail matters for your records: the incident's opening timestamp is the first failure of the streak, not the moment the threshold was crossed. Waiting for confirmation delays the alarm, but never shortens the downtime on record.
Why the default is 1 minute × 3
Networks drop packets and servers have busy seconds, so a single failed check is weak evidence of an outage. Three consecutive failures a minute apart is strong evidence — and it still gets an incident open within about three minutes. Going below that trades reliability for speed: with Failures before incident at 1, every transient blip opens an incident and emails the whole team, which is how alert fatigue starts. See false positives and flapping.
Tuning per criticality
- Client-facing and critical — keep the 1-minute interval; if minutes genuinely matter, lower the failure count to 2 rather than 1. You give up a little confirmation and gain a minute.
- Known-flaky targets — a link that drops a check now and then is better served by raising the failure count (5 or more) than by stretching the interval: you keep per-minute data for the charts while the alarm gains patience.
- Low-priority internal systems — a 5-minute interval is fine, and reduces noise from systems nobody will fix at 3 a.m. Accept that detection stretches accordingly.
Two side effects of longer intervals are worth knowing. Charts get one data point per interval, so a 5-minute monitor draws a coarser latency chart. And staleness detection scales with the interval — a monitor is only flagged Unknown after 3× its interval + 30 seconds without a result, so a 5-minute monitor can be silent for over 15 minutes before anyone is told (monitor statuses explained).
These two settings govern up versus down. The third threshold on the form — slow but up — is its own topic: the degraded latency threshold. For the general theory of picking intervals, see monitoring intervals.