schedule, it runs once a day.
Set the interval
Sendschedule when you create a monitor, or change it later with PATCH /v1/monitors/{monitor_id}:
frequency × unit must come to at least 10 minutes and at most 1 year, so unit: "minutes" needs frequency of 10 or more and unit: "days" allows up to 365. Changing the schedule keeps the baseline.
Each monitor runs at its own fixed slot within the interval, derived from its ID, so monitors created together don’t all run at the same moment. The first scheduled run can therefore come sooner than one full interval after you create the monitor. After that, runs are one interval apart. next_run_at on the monitor shows the next scheduled run.
Run now
POST /v1/monitors/{monitor_id}/run queues a run outside the schedule and returns 202 with its run_id. The schedule doesn’t move.
run_id to Retrieve a monitor run to see the outcome. A paused monitor returns 409 MONITOR_PAUSED. Runs of one monitor never overlap: if another run is already in progress, the new one is skipped with skip_reason: "superseded".
Pause and resume
next_run_at is null. Send {"status": "active"} to resume it. A resumed monitor runs promptly, and its counts of consecutive failures and skips start over. Paused monitors still count toward your monitor limit.
Failures and automatic pauses
When a run fails, the monitor’sstatus becomes failed and last_error explains why, but runs continue on schedule. The next successful run sets the monitor back to active. Context.dev pauses a monitor for you, setting status to paused, after any of these:
- 10 failed runs in a row.
- 3 failed runs in a row before the monitor has a baseline.
- 3 runs in a row skipped because your organization didn’t have enough credits.
Related
- Targets: what a baseline run captures.
- Events and alerts: get a
run.completedevent after every completed run. - Run a monitor now reference and Update a monitor reference