Compare monitors before and after a deploy
verify_deployCompare monitor checks before and after a deploy to detect regressions by returning PASS, REGRESSED, FAIL, or INSUFFICIENT_DATA per region without running new checks.
Instructions
Compare monitors before and after a deploy, without running any check. For each monitor it compares the checks since since with the 24 hours before it, per region, and returns verdict PASS, REGRESSED (most regions slower or failing more than in the baseline, or one region failing), FAIL (most regions failing now, or an incident opened since since) or INSUFFICIENT_DATA (too few checks yet: wait retry_after_seconds and call again; or too little history: say so and stop). These verdicts are not monitor statuses: REGRESSED is not the DEGRADED of list_monitors. Checks run inside a maintenance window count by their result. Each monitor lists its regions with check counts, the median latency since the deploy and the baseline p95 (for HTTP monitors the comparison uses time to first byte when both sides have it; each region's latency_metric says which), plus incidents_since, changes_since (outside changes such as DNS or certificate) and needs_fresh_checks (call check_now on it before retrying). Paused monitors come back in skipped, and deploy markers near since in deploy_markers. Select monitors with monitor_ids or with tag (+ tag_match), never both, at most 100. check_now allows 10 calls a minute, so with many monitors call check_now first on those whose interval_seconds is over 60: the faster ones fill up on their own schedule. Pass the same since on every retry. When retry_after_seconds is null, stop: it turns null 15 minutes after since at the latest. The tool only reads: for fresh points call check_now first. A 5xx on a large selection that repeats after one retry means the check is too large: pass fewer monitors or a later since. Limited to 10 calls per minute per calling address for an API key, per user for an app connection (never per key or organization); past that it is a 429 with the seconds to wait. Example: {"tag": ["service:api"], "since": "2026-11-01T10:02:00Z"}
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Keep items carrying these tags: a JSON array of up to 10 tags, each up to 50 characters, lowercased before matching. tag_match decides whether all or any of them must match. At most 100 monitors (paused included) may match. Not with monitor_ids. | |
| since | Yes | When the deploy finished, ISO 8601 with a UTC offset, for example 2026-11-01T10:02:00Z. At most 24 hours ago; up to 5 minutes ahead is read as now. A time without an offset is a 422. Use the deployed_at you gave record_deploy. | |
| tag_match | No | all (the default): an item must carry every tag in tag. any: at least one of them. | |
| monitor_ids | No | 1 to 100 distinct monitor uuids from list_monitors. A repeated id is a 422 and an unknown id is a 404 naming it. Not with tag. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | The deploy time used (never later than evaluated_at). | |
| counts | Yes | Monitors per verdict. | |
| skipped | Yes | Selected monitors that were not judged, such as paused ones. | |
| verdict | Yes | Worst verdict of the monitors; INSUFFICIENT_DATA when none were judged. Known values: PASS, REGRESSED, FAIL, INSUFFICIENT_DATA. | |
| monitors | Yes | Judged monitors, worst verdict first, then by name. | |
| baseline_to | Yes | End of the baseline hours (exclusive). | |
| evaluated_at | Yes | When the check was computed. | |
| baseline_from | Yes | Start of the baseline hours. | |
| deploy_markers | Yes | Up to 5 recorded deploys near `since` that touched these monitors. | |
| latency_metric | Yes | The latency every region was compared on, or mixed when regions differ; each region row names its own; response_time_ms when no monitor was compared. Known values: response_time_ms, ttfb_ms, mixed. | |
| retry_after_seconds | Yes | Largest wait among monitors that waiting can help; null when none. |