# 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[​](#request "Enlace directo al request")

## Responses[​](#responses "Enlace directo al Responses")

* 200
* 404
* 422

Successful Response

Not found

Validation Error