Skip to main content

Checks

Monitoring check management

📄️Update several checks at once

Applies one set of `changes`, shaped like a single-check PATCH body, to every check of `checkUids`, with exactly the semantics of that PATCH (spec 2026-11-05-01). Only the fields of `BulkCheckChanges` are accepted; any other field is a `VALIDATION_ERROR`, never silently ignored. Per-check: a check the changes cannot apply to (a placement change on a passive check, a value its PATCH would reject, a read-only demo check, a check not in this organization) is reported in `skipped` and the others are still updated. `dryRun` runs every validation and writes nothing; it checks each check against the current state, so it cannot see a plan limit only the earlier checks of the same batch would exhaust.

📄️Switch pinned checks to automatic placement

**Deprecated, removed after 2026-12-15**: use `PATCH /api/v1/orgs/{org}/checks` with `{'placement': 'auto'}`. Responses carry `Deprecation` and `Sunset` headers. The checks list's bulk action (spec 2026-09-25-06). Each eligible check becomes `placement: auto` with `regionCount` = its current region count and an empty pool; its regions and jobs are untouched, so neither its cost nor where it runs today changes — it only gains failover when one of its regions goes dark. Passive checks and checks naming a private (`@`) region are skipped. With no `checkUids`, every eligible pinned, non-internal check of the organization is switched.

📄️Write and test a js check script from a confirmed contract

Runs SolidPing's agent loop: the LLM explores the target (fetch_page, browser_snapshot) and tests its script (run_script) until a run returns up or the turn cap (SP_AI_MAX_TURNS) is hit. Returns the script, its last run and the js config to save through POST /checks (without the secrets, which only the caller holds). The LLM only ever sees secret names. Nothing is saved. 422 with the last attempt when no script passed. 404 when no AI provider is configured, or when checkUid names no js check of the org. Send `Accept: application/x-ndjson` to get the progress streamed: a 200 whose body is one JSON object per line, `turn`, `message`, `tool`, `toolResult` and `ping` lines while it runs, then a last `result` line (`result` holds the 200 body) or `error` line (`httpStatus` and `response` hold what the plain call would have answered).

📄️List a check's latest screenshots

The check's latest page captures, newest first: the screenshots its incidents carry, the captures of failing runs that opened no incident (a validating run, a blip, a regional failure, a run of an outage whose incident already holds its onset capture), and 'Capture now' captures. A check keeps at most 5 captures of its own (the oldest is retired on the sixth); incident captures live as long as their incident. Any check type answers — a type that never captures returns an empty list. Next to `data`, `captureOutcome` reports the latest 'Capture now' request that produced no screenshot, and why (browser and js checks only). Captures are viewport-only, 1280x800. Operator-only: never exposed on a status page, badge or subscriber payload. Same authorization as reading the check.

📄️Capture a screenshot now

'Capture now': runs a browser or js check once, on demand, with the screenshot forced whatever the verdict (and whether or not the check's own `screenshot` option is on). The run goes through the check's own scheduling, so it executes where the check executes — one of its regions, on a shared worker or on the organization's private agent — and its result is recorded like any other run. The call returns as soon as the run is scheduled; the capture appears in `GET …/screenshots` (trigger `capture-now`, or `agent-upload` from a private agent) once the run completes. A run that completes without a capture is reported as `captureOutcome` on that listing, matched by `requestedAt`. A js check only yields a capture if its script calls `page.screenshot()`. Rate limited to one request per check per minute and 20 per organization per hour; a refusal carries `Retry-After`. Requires write access (viewers get 403).

📄️Run a check once, now

'Run now': runs any check once, on demand, in every region, instead of waiting for its next period. Each region's job is made due at once and the workers are told; a region whose job is mid-run keeps the request and runs again as soon as that run ends (its current run started before the request, so it is not the answer). Every region is reported `queued`. The results go through the normal path, so they can open or resolve an incident like any scheduled result. A result with `periodStart >= requestedAt` is this request's answer. This is an action path: it does not create the multi-step run resource at `…/run`. Rate limited per check and per organization (3 per minute and 60 per hour; browser, js, rdp and vnc checks 1 per minute and 20 per hour); a refusal carries `Retry-After`. Requires write access (viewers get 403).