PackEdge

Appearance

Auto-disable ​

PackEdge tracks consecutive delivery failures for every webhook subscription. When a subscriber URL fails six times in a row, the webhook is automatically disabled — no more events are queued for it until you re-enable it.

This protects two things at once: your subscriber from getting drowned in retries after it's already broken, and PackEdge's worker capacity from being spent on a dead endpoint.

Threshold ​

  • Six consecutive failures flips the enabled flag to false.
  • The failure counter only increments on attempts that returned an error or a non-2xx status.
  • A successful delivery (any 2xx) resets the counter to zero, so an occasional 502 won't get you anywhere near the threshold.

What happens when it triggers ​

  1. The dispatcher sets webhooks.enabled = false, records the disabled_reason (last error message), and stamps disabled_at.
  2. An email is sent to the developer who owns the webhook's product. It names the webhook, the failing URL, and links to the per-webhook detail page.
  3. An in-app notification is fired with the same content so the developer sees a badge in the console even if they miss the email.
  4. The webhook stops appearing in dispatch lookups. Pending retry deliveries are not auto-cancelled — they exhaust their retry schedule and then go quiet.

Re-enabling ​

There are two ways to bring a disabled webhook back:

  • Console — Open the product's Webhooks tab, click the disabled webhook, and hit "Enable". The failure counter is cleared at the same time.
  • Update the URL — Editing the URL (any change) clears the failure counter and re-enables the row in a single step. Useful when the original endpoint was redeployed to a new host.

Either path resets the counter to zero. If the same endpoint keeps failing, you'll trip the threshold again at the next batch of six consecutive failures.

Why not back off and keep trying? ​

Single-delivery retry already does exponential back-off (up to 24h between attempts on the same event). The 6-failure threshold is about streaks, not individual deliveries — when every event in a row has failed, the endpoint isn't transiently down, it's broken. Stopping until the operator looks is the right call.