Skip to main content
Every call below acts on a monitor you already created — see the Quickstart.

List monitors

list returns your organization’s monitors, paged with since and before and terminated by has_more. The default page size is 100 and the maximum is 1000.

Read one monitor

get returns the monitor together with its run_state, so one call gives you both the configuration and the state of the schedule.
There is no separate run_state method — get() returns both. See Reference.

Update a monitor

An omitted field keeps its current value. Updates carry no precondition and are last-writer-wins.
Setting search_requests replaces the list wholesale. A request keeps its id and its health when every field of its body is unchanged, so editing one query does not reset the others. A monitor must always hold at least one request, so an empty list is not a way to clear them: it leaves the list as it was. A request takes the same filters as a one-off search. A relative bound is re-evaluated on every run, so from_date: "now-7d" is a window that moves with the monitor; an absolute date does not. See Filter by date.

Pause and resume

Pausing is an update that sets status. A paused monitor keeps its configuration and its records but does not run. A monitor can also be paused for you. A skipped run’s status_reason says why. Resume a monitor paused this way with an ordinary update once the cause is fixed.
The cURL and SDK tabs above do the same thing — the same status value is spelled differently per transport. See Reference.
Setting the status at create time is how you create a monitor without starting its schedule.

Delete a monitor

Deleting is permanent. Every record becomes invisible at once, and the name is released for a new monitor to take.