Consensus & status
ZeroDrop runs every check from four locations. Consensus is how it turns those four independent opinions into a single verdict, and the reason it stays quiet until something is genuinely wrong.
The three states
A check is always in exactly one state:
| State | Meaning |
|---|---|
| ok | Consensus says the service is healthy. |
| firing | Consensus says the service is down. There's an open incident. |
| unknown | ZeroDrop can't see enough locations to judge. Monitoring has gone blind. |
How a verdict is reached
On each interval the evaluator looks at the live locations (those that reported fresh results and aren't quarantined) and counts how many are failing. A check is breached for that evaluation when both of these hold:
- the failing fraction of live locations is at least the configured fraction, and
- the absolute number of failing locations is at least the configured floor.
A breach doesn't fire immediately. The check must be breached for several consecutive evaluations before it transitions to firing, and healthy for several consecutive evaluations before it returns to ok. This debouncing is what filters out blips.
Tuning thresholds
Each check carries its own consensus configuration, editable from the check form:
| Setting | Default | What it controls |
|---|---|---|
| Floor (locations down to alert) | 2 | Minimum number of locations that must report down at the same time, regardless of fraction. |
| Fraction | 0.5 | Share of live locations that must fail to count as a breach (for example 0.5 = half). |
| Fire evals | 2 | Consecutive breached evaluations before the check fires. |
| Resolve evals | 2 | Consecutive healthy evaluations before the check resolves. |
| Min live locations | 3 | Below this many live locations the check is unknown, never fired. |
By default a check needs at least two locations to agree it's down before it fires, so a single flaky network or region can't raise a false alarm.
Make a check more sensitive by lowering the floor (to 1), the fraction, or
the fire-evals. Make it more conservative by raising them, which helps for
endpoints that are occasionally slow but not truly down.
Why "unknown" exists
If fewer than the minimum live locations are reporting, whether from a network partition, an agent outage, or your firewall blocking some regions, ZeroDrop refuses to guess. Instead of firing a possibly-false alarm, the check goes unknown.
This is a deliberate fail-safe. A check that was being monitored and then loses visibility emits a monitoring blind notification; when visibility returns it emits monitoring restored. These are not incidents. They tell you ZeroDrop's view is degraded, not that your service is down. See Incidents & alerts.
Transitions at a glance
| Transition | Event | Incident? |
|---|---|---|
| ok to firing | Fire, incident opened | Yes |
| firing to ok | Resolve, incident closed | Yes |
| ok/firing to unknown | Blind, monitoring lost visibility | No |
| unknown to ok/firing | Restore, monitoring resumed | No |
Your notifications are driven by exactly these transitions, so you hear about a change in state rather than a steady stream of updates. If you do want reminders while an incident stays open, enable repeat reminders in Settings.