Check Retries and Alert Thresholds

Why False Positives Happen

A single failed run does not always mean your service is down. A transient network blip, a slow handshake, or one flaky monitoring region can make a healthy endpoint look broken for a moment. LoadFocus gives you three layers that stop these false positives from paging you: retries, a consecutive-failure threshold, and a multi-location threshold.

All three settings live on the check itself, on the New API Check page, and work for API, TCP, DNS and browser checks.

Retries

When a check fails, LoadFocus can retry it before marking the run as failed. A transient blip that passes on retry never becomes a failure. You can configure:

  • Retry count: how many times to retry, from 0 to 5.
  • Retry interval: the wait between retries, from 1 to 60 seconds.
  • Backoff strategy: fixed, linear, or exponential spacing between attempts.
  • Retry region: retry from the same region or from a different one, to rule out region-local noise.
  • Maximum total retry time: a cap on how long all retries together may take.

Consecutive-Failure Threshold

Retries handle blips inside a run, but a check can still produce an isolated bad run. Instead of alerting on the first failure, you can alert only after N consecutive failed runs. If you prefer maximum sensitivity, you can also choose to be alerted on every failure.

Recovery notifications fire when the check passes again, so you always know when the incident is over.

Multi-Location Threshold

When a check runs from multiple regions, you can set how many locations must fail before the check counts as failed. This acts as a quorum: one flaky region cannot page you on its own, while a real outage seen from several regions still does.

How the Three Layers Combine

Each layer absorbs a different kind of noise:

  • Retries absorb blips inside a single run.
  • The consecutive-failure threshold absorbs isolated bad runs.
  • The multi-location threshold absorbs single-region noise.

Together they mean an alert almost always reflects a real, sustained, multi-region problem. For the shared check settings, see How to Create a New API Check. To choose where alerts are delivered, see Alert Channels, and learn more about Uptime Monitoring.