Webhook Gap Alerts: An Issue When Events You Expect Stop Arriving

Last verified on Nov 10, 2026.

What it catches

A webhook gap is silence where traffic should be. A provider stops calling your endpoint, or your endpoint stops logging what it receives, and nothing errors, because nothing happens. That is why these failures last. Nobody sees a red line.

The Sazabi agent sets up sensors for your project and maintains them over time. Sensors are standing questions about your logs, and Webhook gap asks: "Have events that normally arrive from a provider stopped?" It catches:

• A payments, shipping or email provider whose delivery events stop for an hour.
• A webhook subscription that was disabled after repeated failures on the sender's side.
• A signing secret rotated on one end only, so every delivery is rejected before it is logged.
• A proxy or firewall rule that started dropping the sender's requests.
• A single event type that goes missing while others keep arriving.

Example: delivery events disappear

This is an example, not output from a real project. Your mail-events endpoint receives delivery and bounce callbacks from an email provider, and it logs one line per event. The usual evening rate is a few hundred lines an hour.

2026-11-08T17:58:44Z INFO  mail-events received type=delivered provider=email-provider message_id=m_88a1
2026-11-08T17:58:52Z INFO  mail-events received type=bounced provider=email-provider message_id=m_88a4
2026-11-08T17:59:03Z INFO  mail-events received type=delivered provider=email-provider message_id=m_88b0
(no further lines from mail-events until 19:06)

Nothing is logged after 17

An example issue:

• Name: Email provider delivery webhooks stopped arriving at mail-events
• Description: No delivery or bounce events have been received since 17
  UTC, while sends from your application continue. The endpoint usually logs several hundred events an hour in the evening.
• Severity: high
• Component: mail-events

The sends from your own application are the evidence that matters. They show the provider is still being used, so the silence is not simply low traffic.

How Sazabi sets it up

You set nothing up. The Sazabi agent writes and maintains the sensor for your project. Regular daily and weekly rhythms are part of normal traffic and do not count as a gap.

When a gap is detected, the agent investigates. It checks whether the rest of your logs look normal, whether your own sends continued and whether the gap is on one event type or all of them. The issue opens only when the problem is real.

What you see and how you get told

You get an issue with a name, a description, a severity and the evidence. Issue triggered notifications reach you through the channels you chose, and a delivery rule can send high issues on one component to a shared channel. Ask the agent in the thread when the last event arrived and which senders are affected. sazabi signals list --type sensor shows the signal underneath.

What it does not cover

• It cannot see events that never reach a log. If your endpoint does not log what it receives, there is nothing to count.
• It does not talk to the sender or read its delivery dashboard.
• It does not replay or backfill missed events.
• A feed that is current but wrong is a data question for reconciliation mismatches.

Related

For the manual version, see the guide to webhook monitoring. Provider-specific setup is under webhook integrations. A provider that answers your calls slowly is vendor degradation. Detected issues are metered, so check pricing.