Failure Handling & Backoff
How OpsKitty handles consecutive failures and uses thresholds to control alert noise.
Failure threshold
The failure threshold is the number of consecutive failed checks required before an alert fires. A threshold of 3 means OpsKitty must see 3 failed checks in a row before notifying you. This prevents single transient errors (a momentary network blip, a brief server hiccup) from waking up your team.
Success threshold
The success threshold controls how many consecutive successful checks are required before a triggered alert is marked as resolved. This prevents a flapping endpoint from rapidly toggling between triggered and resolved states. A threshold of 2 means the endpoint must pass 2 checks in a row before the alert resolves.
Send on resolved
When "notify on resolved" is enabled, OpsKitty sends a follow-up notification once the success threshold is met and the alert resolves. This lets your team know the issue is fixed without manually checking the dashboard.
Exponential backoff
When an endpoint remains down for an extended period, OpsKitty gradually increases the time between checks using exponential backoff. This reduces unnecessary load on a host that is clearly offline and avoids your monitoring traffic being flagged as abusive by firewalls or WAFs.
| Consecutive failures | Next check delay (60s base) |
|---|---|
| 1–3 | 60s (normal interval) |
| 4 | 120s |
| 5 | 240s |
| 6+ | Max 15 minutes |
As soon as the endpoint recovers, the interval resets to its normal configured value immediately.