Monitor
A monitor is the thing you configure: a target, a type, an interval, and a rule for what counts as success. It has a current state and a history of check results.
Every monitor belongs to a workspace. Twenty monitors per workspace.
Check result
One observation, at one point in time: did it succeed, how long did it take, what status came back, and what the failure was if it failed.
Every result carries an ID generated by whatever produced it. If the prober submits a batch, loses the connection before seeing the response, and retries, the replay is recognised and discarded.
This is why a network blip cannot page you twice for one outage — and why the same mechanism protects the heartbeat endpoint from a job that retries its ping.
Raw results are kept for 7 days and then deleted. There is no long-term rollup, so uptime percentages cover the last 24 hours and the last 7 days, and nothing longer.
State
Three values.
| State | Meaning |
|---|---|
pending |
Not yet established. Either the monitor has never completed a check, or it is failing but has not reached its threshold. |
up |
The last check succeeded. |
down |
Consecutive failures reached the threshold. An incident is open. |
pending is the state people ask about most. It exists so a single blip does not become an
incident.
Failure threshold
How many consecutive failures before a monitor is declared down. Default 2, range 1–10, per monitor.
Worked through:
| Check | Result | Failures | State |
|---|---|---|---|
| 1 | ok | 0 | up |
| 2 | fail | 1 | pending |
| 3 | fail | 2 | down — incident opens, alerts fire |
| 4 | fail | 3 | down — no new incident, no new alert |
| 5 | ok | 0 | up — incident resolves, recovery alert fires |
Two things to note.
Recovery is a single success. However long the outage ran, one successful check resolves it. Requiring several would delay the all-clear for no benefit.
The counter resets on success, not over time. Two failures an hour apart with a success between them is not two consecutive failures.
Raise the threshold on a flaky network to trade alert speed for fewer false alarms. Set it to 1 when you would rather know immediately.
Incident
Opened when a monitor crosses its threshold; resolved on the first success afterwards.
Exactly one incident per outage. A monitor that is down and keeps failing does not accumulate incidents. This is enforced rather than assumed: if a transition were somehow interrupted, the next failure finds the existing open incident instead of creating a second.
An incident records when it opened, when it resolved, the reason it opened, and the external verdict if one was recorded.
Alerts
Alerts are messages. Incidents are state. Two events produce alerts:
- opened — the monitor crossed its threshold
- resolved — the monitor recovered
Plus reminders while an incident stays open, if you enable them.
Alerts are dispatched after state has been committed, and every delivery attempt — success or failure — is recorded in a ledger. A broken channel is therefore visible, and cannot change what a monitor believes about its target.
Cadence: probed vs scheduled
Two groups of monitor type, and the distinction explains most of the defaults.
Probed — HTTP, TCP, heartbeat. Run by the probe worker at your interval, from 20 seconds. Liveness changes minute to minute, so it is worth polling.
Scheduled — certificate, domain, DNS, email auth. Run from the backend, default once a day. A certificate does not stop being valid between one minute and the next; checking hourly would return the same answer 24 times.
You can shorten a scheduled monitor’s interval. It is rarely useful.
Workspace
Monitors, channels and members belong to a workspace. Members have roles; owners and admins can change configuration.
A monitor in one workspace cannot be attached to a channel in another. This is enforced at the API, not just hidden in the interface.