Deliveries and retries

DomainDash records every webhook it tries to send, so you can see exactly what was delivered, what your endpoint returned, and replay anything that didn't get through.

TIP

Outbound webhooks are part of the Pro and Business plans. See outbound webhooks for how to set them up.

How a delivery works

When an event fires for a site in your team, DomainDash creates a delivery for each endpoint subscribed to that event and sends it as a signed POST request to your endpoint's URL.

DomainDash treats any 2xx response from your endpoint as success. Anything else — a 4xx, a 5xx, a timeout, or no response at all — counts as a failure and will be retried.

Recent deliveries

The Recent deliveries table on the Webhooks page shows your most recent deliveries, newest first. Each row shows:

• Event — the event type, such as site.went_down.
• Status — pending, success, or failed.
• Response — the HTTP status code your endpoint returned (or a dash if there wasn't one).
• Attempts — how many times DomainDash has tried to deliver it.
• Time — when it was delivered, or when it was created if it hasn't been delivered yet.

This is your quick audit trail: confirm an event was sent, see what your endpoint said back, and spot anything that failed — no guessing whether DomainDash did its part.

Retries with backoff

A single failed delivery isn't the end of the road. DomainDash retries failed deliveries several times, waiting longer between each attempt — known as exponential backoff. The first retry comes quickly, then each subsequent attempt waits progressively longer, giving a briefly unavailable endpoint time to recover before DomainDash gives up on that event. So a momentary blip on your side won't cost you the event.

Because deliveries can be retried, your endpoint should be idempotent: use the webhook-id header to recognise an event you've already processed, so a retry of an event you handled successfully doesn't cause it to be processed twice.

When an endpoint is disabled

If an endpoint fails too many times in a row, DomainDash disables it automatically to stop pointlessly sending events to a URL that isn't accepting them. A disabled endpoint shows a status of "Too many failed deliveries" and stops receiving new events.

To bring it back, fix whatever was wrong on your side, then edit the endpoint and re-enable it. Re-enabling resets the failure count, so it starts fresh.

Replaying a delivery

If a delivery failed — or you want to re-send one for any reason — use Replay on its row. DomainDash re-queues that exact delivery and sends it again, with a fresh attempt count and the same signed payload.

Replaying is handy when your endpoint was briefly down and you want to catch up on events it missed, or when you've just fixed a bug in how your endpoint handles a particular event type. Nothing slips through the cracks — you can always go back and pick up what you missed.

Only the team owner and admins can replay deliveries.

Frequently asked questions

What counts as a successful webhook delivery?

DomainDash treats any 2xx response from your endpoint as success. Anything else — a 4xx, a 5xx, a timeout, or no response at all — counts as a failure and will be retried.

What happens when a delivery fails?

DomainDash retries failed deliveries several times, waiting longer between each attempt — exponential backoff. The first retry comes quickly, then each subsequent attempt waits progressively longer, giving a briefly unavailable endpoint time to recover, so a momentary blip on your side won't cost you the event.

Why was my endpoint disabled?

If an endpoint fails too many times in a row, DomainDash disables it automatically to stop pointlessly sending events to a URL that isn't accepting them. It shows a status of "Too many failed deliveries". To bring it back, fix whatever was wrong on your side, then edit the endpoint and re-enable it — re-enabling resets the failure count.

Can I re-send a webhook that failed?

Yes. Use Replay on the delivery's row and DomainDash re-queues that exact delivery with a fresh attempt count and the same signed payload. It's handy for catching up on events a briefly down endpoint missed. Only the team owner and admins can replay deliveries.

Related

• Outbound webhooks for setting up endpoints, events, and the signing secret
• How incidents work for the events that trigger deliveries
• Plans and pricing for which plans include webhooks