Hanzo
OpenapiO11y

Replay the alert records this process took

Answers the most recent Alertmanager deliveries THIS process received, as plain text — one greppable `ALERT-RECEIVED` line per alert, followed by the…

GET /v1/o11y/alerts/last

Addresshttps://api.hanzo.ai/v1/o11y/alerts/last
MethodGET
Operationget_o11y_alerts_last
AuthAuthorization: Bearer $HANZO_API_KEY

Answers the most recent Alertmanager deliveries THIS process received, as plain text — one greppable ALERT-RECEIVED line per alert, followed by the ALERT-DELIVERED / ALERT-UNDELIVERED outcome of carrying it out of the process, newest last, so piping to tail reads in arrival order. (none) when nothing has landed.

Arrival and delivery are separate lines because they are separate facts that fail independently. Alertmanager can tell you it dispatched a notification, never that anything received it; this process taking the call says nothing about whether a human was reached. Reading only the first as if it were the second is how a pager stays silent for months behind a log where everything looks fine.

The ring is PROCESS-LOCAL and bounded to the last 200 lines. Both are the point: a record that outlived the process that took the call would be a claim about something nobody observed, and an unbounded log is a memory leak with a nice name. A restart empties it.

Request

GET /v1/o11y/alerts/last takes no parameters and no body — the credential is the whole request.

Response

The document declares no response body for this operation. It answers 200 on success and the platform error shape on failure — see Errors.

Examples

hanzo o11y alerts last

O11y API · All Hanzo APIs · Interactive reference

How is this guide?

On this page