Docs

The monitor lifecycle

How a monitor's status is confirmed, what pausing and maintenance do, and what editing and deleting change.

This page explains what happens to a monitor from its first check to its deletion: how a status is confirmed, how pauses and maintenance stop it, and what an edit changes.

#The first check

Saving the form runs the first check at once, so a new HTTP, Keyword, API, Port, or DNS monitor spends only a moment as Pending before it shows a real status. A heartbeat stays pending until your job's first ping arrives, so wire the ping in right after creating it. A scheduler runs at its next scheduled slot.

#Every interval after that

Checks run on wall-clock slots. A 5 minute monitor runs at :00, :05, :10, and so on. The result of each check is up, slow, or down, and a streak of results changes the monitor's status:

  • The failure threshold (3 by default) is the number of consecutive failed checks that confirm a down. One blip is not an outage.
  • The recovery threshold (1 by default) is the number of consecutive passing checks that confirm the recovery.
  • Moving between up and slow also takes a streak as long as the failure threshold.

Heartbeat and scheduler monitors have no thresholds. A heartbeat goes down the moment a ping is later than its interval plus its grace, and a scheduler's status is the result of its latest run.

Every confirmed status change is recorded in the monitor's activity log with the check's detail, such as HTTP 503, timeout, or the content rule that failed.

#From status to alert

A confirmed status does not alert by itself. The project's incident policy decides how long a problem has to last first (5 minutes by default) and how long a recovery has to hold (10 minutes by default). Heartbeats and schedulers alert at once. See When alerts fire.

#Paused

Choose Pause on the monitor page and checks stop: nothing runs, nothing is recorded, nothing alerts, and a paused heartbeat answers its ping URL with 404. Choose Resume and checking continues at the next slot. Pause is for "stop watching this for now". For downtime that is planned and has an end, a maintenance window is the better tool.

#Under maintenance

While a maintenance window covers a monitor, its checks do not run. The recent-checks bar records the gap, so a deploy reads as a hole instead of an outage, no alert fires, no incident opens, and the time is left out of the uptime figure. When the window ends, checking resumes at the next slot. See Maintenance windows.

#Above your plan's limit

If an account ends up with more monitors than its plan allows, for example after a downgrade, the oldest monitors up to the limit keep running and the rest stop being checked. They start again as soon as the account is back within the limit. Monitors above the limit are never deleted. See Plans and limits.

#Edited

Everything except the type can change after creation, from Monitor settings or with a PATCH over the API: target, method, interval, thresholds, rules, headers, body. A new interval takes effect from the next slot. Stored header values are kept unless you replace them. Changing the URL clears the cached certificate and domain expiry dates, which are looked up again within a day.

#Deleted

Deleting a monitor removes it and its whole history: checks, activity, incidents, and its place on the status page. The dashboard asks you to type the monitor's name to confirm. This cannot be undone. A deleted heartbeat's ping URL stops answering, so remove the ping from the job it was watching.

#What's next?