Hanzo
OpenapiO11y

Take an Alertmanager notification and page a human

Records one Alertmanager webhook delivery and pages the on-call.

POST /v1/o11y/alerts/{receiver}

Addresshttps://api.hanzo.ai/v1/o11y/alerts/{receiver}
MethodPOST
Operationpost_o11y_alerts_by_receiver
AuthAuthorization: Bearer $HANZO_API_KEY

Records one Alertmanager webhook delivery and pages the on-call. Each alert prints an ALERT-RECEIVED line and joins the replay ring, then the batch is carried out of the process by the egress chain: the org's KMS-custodied Slack bot token first (the ONE product Slack egress, not a second webhook credential), falling back to a plain POST to CLOUD_ALERTS_WEBHOOK_URL — which needs no Slack connection and so works in exactly the state that silences the first. Resolved notifications page too: "it recovered" is the half of an incident people are actually waiting for.

THE STATUS CODE REPORTS DELIVERY, NOT ARRIVAL. 200 ok means an egress accepted the batch. If none did — including when none is configured at all — it answers 503 naming the failure, so Alertmanager retries and counts it in alertmanager_notifications_failed_total. An alert nobody could be told about must never answer the same way as one that was delivered.

A body that will not parse is still recorded (with empty fields) rather than rejected: the delivery happened, which is the fact being recorded, and a 400 would make Alertmanager retry a malformed payload forever.

The receiver segment is Alertmanager's own receiver name, a parameter rather than a hand-listed route because the receiver set is config, not code.

Request

1 field.

FieldInTypeRequiredDescription
receiverpathstringyes

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 add <receiver>

O11y API · All Hanzo APIs · Interactive reference

How is this guide?

On this page