A webhook that fails 20 deliveries in a row is disabled and your team gets an email.

A broken webhook endpoint used to fail in silence. We retried each delivery five
times, wrote the failure to the event log, and then moved on to the next event
and did the same again.

20 strikes, then we stop

Each delivery that uses up all five of its retries counts against the endpoint. A
single successful delivery resets the count to zero, so a slow minute or a
restart costs you nothing. Twenty failed deliveries in a row is different — that
is an endpoint that is not coming back on its own, so we stop sending to it.

The webhook then shows as Disabled on the webhooks page, with the reason, and
new events are not delivered to it.

Your team hears about it

Everyone in the organization with an owner, admin or developer role
gets an email the moment it happens. It names the endpoint, shows the last error
we saw — the status code or the timeout — and links straight to the webhook.

Moderators are left out of it: they cannot fix an endpoint, and it is not their
alert to carry.

Turning it back on

Fix the endpoint, then open Configure → Webhooks and choose Enable on the
disabled row. Deliveries resume immediately and the counter starts again from
zero.

Events that fired while the webhook was off are not queued up and replayed at
you. What you can do is replay them one by one from the event log, so you choose
what is still worth delivering rather than being handed a backlog.