Skip to main content
Every execution of a monitor produces a run, whether or not it found anything. Read runs to tell a quiet monitor from a broken one. The examples below start from a monitor you already created — see the Quickstart.

List runs

Run history is newest first, so the first run in a page is the latest. Runs page on run_id, not on a cursor token: page back with before, or ask for ascending order and walk forward with since. Both cursors are exclusive, and has_more tells you whether more remain.

Read one run

Fetch a single run by id when a webhook delivery tells you one finished.
A run carries requests_total, requests_ok and requests_failed, which say how many of its searches worked. Which ones is a separate call.

Read a run’s per-request breakdown

list_run_requests returns one entry per search request on the config the run executed. It is not paged — there is no cursor and no has_more, because a monitor holds at most 1000 requests and the whole set comes back at once.
results_returned against new_records is what separates “working, nothing new” from “this query returns nothing” from “this request is failing”:
  • results_returned high, new_records zero — the query works and the web has not moved. Nothing to do.
  • results_returned zero across every run — the query itself matches nothing. Rewrite it.
  • status reports the request as failing — the search did not complete. reason carries prose explaining it; there is no error code.

Read one run’s records

first_record_id and last_record_id on a run are a bound, not a dense sequence. To read one run’s records, ask for them rather than doing arithmetic on ids.
This reads one page. A first run is the largest a monitor produces, so page with since while has_more is set.