Saltar al contenido principal

Test Alert

POST 
/v1/alerts/:alert_id/test

Run this alert once now, outside its schedule. IT MAILS ITS RECIPIENTS.

A test run is a live send, not a dry run. Once the capture exists, every address on the alert — email, Slack webhook, in-app user — is reached exactly as on a real fire: deliver_alert_capture runs the channels before it ever looks at the delivery kind. That is what testing an alert means, and it is the only way to see the message a recipient actually gets. What the test kind changes is the BOOKKEEPING, not the send: lastFiredAt does not move and an error status is not cleared, because nothing fired. For a check that reaches nobody, use POST /v1/alerts/{alert_id}/verify (resolves the recipe, captures nothing, sends nothing) or POST /v1/alerts/{alert_id}/backtest.

It says what a firing would say. The condition is run READ-ONLY so the body carries the alert's own say sentence, rendered from a row measured just now — the point of the button being to answer "what will my team see?" before the alert is live, and the alert's name being the one part of that the author already knows. A template with a placeholder nobody filled, or one that reads badly with a real number in it, is visible here instead of at the first real breach. When the condition cannot be run the send still goes out and says so, with the engine's own words for why.

And it cannot be mistaken for a firing. Every channel marks it: the subject carries a test-run label, the body says nothing fired and that the alert's schedule and history were left untouched, the in-app title does not say "triggered". A rehearsal a recipient reads as a performance is a worse defect than a contentless one.

Measuring is not evaluating: lastEvaluatedAt, lastVerdict, status and lastFiredAt are all untouched, so a hand test cannot consume the slot the schedule was going to use, silence the fire that follows, or call a healthy alert broken.

202 is an acknowledgement, not a delivery. Read executed and status.

  • queued + executed: true + deliveryId — the capture recipe was handed to the renderer. deliveryId is the Screenshot EXPORT row (the record dashboard subscriptions already use); poll it. The lane is asynchronous by construction — only the image-based playwright lambda owns a browser — so this route cannot report a finished capture, and never claims one.
  • not_executed + executed: false — nothing ran, and message says why: this deployment cannot reach the renderer, the viz is gone, the alert has no user to impersonate, or the recipe was refused before a browser was booked (over 20 steps).

captured means an object exists in storage, and failed names the recipe step that broke; both are what the delivery row carries once the renderer is done. lastEvaluatedAt is untouched here — a capture is not an evaluation (that is slice 4). It never says success.

Request​

Responses​

Successful Response