Skip to content
Glowo
Esc
navigateopen⌘Jpreview
On this page

Delivery history and retries

See whether an alert actually arrived — and what Glowo does when a channel is failing.

“Did the alert actually go out?” is a question you want answered before an incident, not during one. Every delivery attempt is recorded.

GET /notifications/<channel-id>/deliveries

In the dashboard this is the Deliveries view on a notification channel.

What a delivery record tells you

  • Which event and which monitor it was for.
  • Which attempt this was.
  • Whether it succeeded, and the error if not.
  • When it happened.

Retries

A failed delivery is retried. Retries carry the same X-Glowo-Delivery-Id and an incremented X-Glowo-Attempt, which is why webhook receivers must deduplicate on the delivery ID.

After repeated failures a delivery is dead-lettered — kept, visible, and no longer retried.

Circuit breakers

Each channel has its own circuit breaker. When a channel fails persistently, Glowo stops hammering it and backs off.

This is per channel, so a Slack webhook that has been deleted cannot slow down or block your email and SMS alerts for the same incident. Channels fan out independently, and one broken integration never suppresses the others.

When alerts stop arriving

Check delivery history for that channel

If deliveries are being attempted and failing, the problem is between Glowo and the provider — a revoked token, a deleted webhook, a changed URL.

If there are no delivery records at all

Nothing was ever sent, so the problem is upstream of delivery. Work through the list in How alerting works — unconfirmed failure, maintenance window, acknowledgement, event subscription, scoping, or a disabled channel.

Send a test

The Test action uses the real configuration and delivery path, which separates “the integration is broken” from “the alert never fired”.

Was this page helpful?