The monitor lifecycle

A monitor's life is simple on purpose: it is born checking, it keeps checking on its interval, it can be told to be quiet on purpose, and everything in between shows up on its timeline. This page walks the whole arc.

#Born checking

Saving the form runs the first check immediately, so a new monitor spends only a moment in pending before showing a real status. There is no waiting for the first interval slot to come around.

The one exception is a heartbeat: it is inbound, so it stays pending until your job's first ping arrives. Wire the ping in right after creating it.

#Every interval after that

The monitor comes due on its interval, the check runs, and the result is judged into up, slow, or down. What flips the monitor's overall status is not one check but a streak:

• fail_threshold consecutive failures (3 by default) turn it down. One blip is not an outage.
• recover_threshold consecutive passes (1 by default) turn it back up.
• Both transitions alert: down tells you it broke, recovery tells you it healed.

Every transition is recorded as an event on the monitor's timeline, so the history of a rough night reads as a sequence, not a mystery.

Two types opt out of the streak logic, because their tolerance is built in differently: a heartbeat's window is its interval plus grace, and a scheduler's every run is its status. Both are covered in Check types.

#Paused

Flip a monitor off and checks stop entirely: nothing runs, nothing is recorded, nothing alerts. Flip it back on and checking resumes on the next interval slot. Pause is for "stop watching this for now"; if the quiet time is planned and has an end, a maintenance window is the better tool.

#Under maintenance

A maintenance window is scheduled quiet, for one monitor or a whole project. While it is active, checks are skipped rather than run-and-ignored, and the uptime bar records the gap as it happens, so a deploy reads as planned downtime instead of an outage. No alerts fire, no incidents open. When the window ends, checking resumes on its own.

#Edited

Everything on a monitor can change after creation, from the settings sheet or a PATCH over the API: URL, interval, thresholds, rules, headers. Stored header values are write-only and survive edits untouched unless you replace them (see Requests and rules). Interval changes take effect from the next slot; there is no restart or downtime in the monitor's own history.

#Deleted

Deleting a monitor removes it from your dashboards, your status page, and the API. A deleted heartbeat's ping URL stops answering, so remember to unwire the curl from the job it was watching.