Skip to main content
A monitor runs on a fixed interval, from every 10 minutes to once a year. Without a schedule, it runs once a day.

Set the interval

Send schedule 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.
Pass 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

A paused monitor doesn’t run, and its 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’s status 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.
Fix the cause, then resume the monitor. Runs and changes lists the error codes and skip reasons.