retry_dead_webhook_deliveries
Replay every webhook delivery the team dead-lettered since an instant, once the consumer is fixed. Defaults to the last 24 hours.
The application's Replay button. After a consumer outage, every row that ran out of retries sits in the dead tab; this tool puts all of them since since back on the ladder in one call and answers with how many it retried. Omit since for the last 24 hours, the window the application uses.
Every replayed row posts its event again
Confirm the consumer is healthy first, a test with
test_webhook_endpoint
is the cheap check, or the same rows dead-letter a second time. Only
dead-lettered rows are touched; failed rows still on the ladder retry on their
own.
since may not be in the future. One call replays at most the number of rows meta.limit states; when retried equals it, call again for the rest. Repeating the call after a complete replay retries nothing, because the rows are no longer dead.
Requires ability
The token behind the MCP session must hold it, or the call is refused with TOKEN_MISSING_ABILITY.
Runs the same action as
The REST endpoint and this tool share one action, so validation, permissions and events are identical.
Annotations
A client that honours annotations asks a person before running it. It reaches beyond Zuse Bifrost: a repository host, a pipeline, a chat or an email.
Arguments
sincestringoptionalISO 8601 instant; only rows dead-lettered at or after it are replayed. Defaults to 24 hours ago.
What it returns
{ "data": { "retried": 17, "since": "2026-10-25T09:20:00+00:00" }, "meta": { "limit": 500 }}since echoes the instant actually used, so a call with no argument shows the 24-hour boundary it applied.
How it fails
VALIDATION_FAILEDsince is malformed or in the future.
AUTHENTICATION_REQUIREDno authenticated user on the request.
TOKEN_MISSING_ABILITYtoken lacks webhook-delivery:retry.
How is this guide?
Last updated on