Disable a webhook endpoint when it returns 410 Gone, and when it fails consistently over a long period, then tell the customer through another channel. Until that point, retry with exponential backoff and jitter, treating any response other than 2xx as a failure.
Definition
A disabled endpoint is a subscription your system has stopped delivering to. The Standard Webhooks specification describes two triggers. A 410 Gone response means the sender should disable the endpoint and stop sending it messages. Consistent failure over a long period means the sender should notify the consumer through other channels and disable future delivery.
The spec does not define how long a long period is, so you must choose and publish your own.
Why it matters for security
Endless retries to a dead URL have costs. They burn worker capacity and can be abused: an attacker who registers many unreachable or slow URLs can try to tie up delivery workers. Domains also change hands. If a customer lets a domain lapse and a stranger registers it, your retries could deliver event data to that stranger. Disabling stale endpoints limits that exposure.
A policy you can adopt
| Condition | Action |
|---|---|
| 2xx | Success, stop retrying |
| Non-2xx or timeout | Retry on a schedule with exponential backoff and random jitter |
| 410 Gone | Disable endpoint, stop sending, notify the owner |
| Repeated failure across your retry window | Mark failing, alert the owner by email and in the dashboard |
| Still failing after your published limit | Disable and require manual re-enable |
| Re-enabled | Send a test event first, then resume |
The spec suggests retrying across multiple days. Use the same webhook id on every retry so receivers can detect duplicates. See how receivers handle replays and duplicates.
Steps
- Write down your retry schedule and the point at which you disable. Publish both in your docs.
- Treat 410 as an explicit signal and honour it right away.
- Notify through a second channel, such as email to account admins, before and after disabling.
- Keep an event log so a re-enabled endpoint can replay missed events within your retention window.
- Require verification when a new URL is added, for example a challenge the receiver must answer, so you do not send data to an unconfirmed address.
- Review endpoints that have been failing for a long time and ask the owner whether they still exist.
Where Safeguard fits
Safeguard's asset discovery and policy features help you keep an inventory of integrations and outbound destinations. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Is a 500 a reason to disable at once?
No. A 500 is a failure to retry. Disable on 410, or after sustained failure by your published policy.
Do I tell the customer?
Yes, through a channel other than the failing webhook, before and after you disable.
Sources
Last reviewed: 19 October 2026.
