Passa al contenuto principale

Verify Alert

POST 
/v1/alerts/:alert_id/verify

Check that this alert's capture recipe still resolves. CAPTURES NOTHING.

The canary. An alert's recipe names the dashboard's controls by the config names an agent chose; rename or delete one and the recipe stops resolving. Run this after editing a dashboard: a red step IS the breaking change, and it is found now rather than when a recipient opens the email.

Read resolved. When it is false, steps[].detail names, per step, what the recipe was looking for and what the dashboard actually declares. Every step is reported — an agent that renamed three selectors is told about three, not about the first.

What this does not do: it captures nothing, delivers nothing, writes no delivery row, sends no email / Slack / in-app message, and moves neither lastEvaluatedAt nor lastFiredAt. captured and rendered are always false. It runs the SAME executor a real capture runs, in resolve-only mode, so it cannot drift from what the capture will do — but it did NOT open a browser: no lambda serving an API route owns Chromium. Resolution is against the dashboard's own generated file tree on branch (the code that produces the DOM, and where the data-selector hooks come from), which is also what GET /v1/viz/{id}/controls reports. A wait_for_paint step therefore has nothing to resolve and says so rather than claiming a pass; the paint gate stays the capture's job.

Read-gated on purpose (VIEW on the alert's dashboard, the same gate as GET /v1/alerts/{alert_id}): verify mutates nothing and derives strictly less than the caller can already get by reading the alert and the dashboard's control manifest — so requiring EDIT would lock a reviewer out of a diagnostic that leaks nothing.

Request​

Responses​

Successful Response