GitHub webhook redelivery: check the receiver, queue and result first

Start with the work already in progress

Before clicking Redeliver on a failed GitHub webhook, find out whether the receiver already accepted it. A receiver can enqueue a job and then lose its HTTP reply. A worker can complete the intended action while GitHub still shows a failed delivery. Sending the webhook again may then start the same work twice. These are possible failure paths, not incidents measured for this guide.

GitHub recommends responding with a 2XX HTTP status within 10 seconds. If the receiver takes longer, GitHub terminates the connection and considers the delivery a failure. Its suggested queue architecture lets the receiver acknowledge the webhook while processing continues in the background.[1] This makes a successful acknowledgment compatible with unfinished work, and a timeout compatible with work already accepted.

GitHub also recommends redelivering missed webhooks after a server comes back up, and documents manual and scripted recovery options.[1][2] The checks here add an application-level decision for integrations that can create consequential effects, such as sending a customer notification or starting an external operation. They do not say that GitHub prohibits redelivery. A harmless, repeatable action may need less investigation than an action whose duplicate matters.

Use the guide with access to the relevant GitHub delivery, receiver records, queue status and a permitted application or provider result lookup. Name one integration recovery owner who can authorize the chosen path. If those inputs are unavailable, the useful result is a documented hold and next evidence check, not a guessed retry.

Trace one delivery through three checkpoints

X-GitHub-Delivery is the delivery header used to identify the GitHub event delivery; its value stays the same on requested redelivery.[1] Retain that value alongside the webhook's source scope, intended target, event type and relevant payload. Link it to the application's job ID and any downstream operation ID. A job ID identifies background work; an operation ID identifies the intended external action. Neither is supplied automatically by the delivery header.

• Locate the original delivery in the correct webhook and preserve its result and failure reason. Read X-GitHub-Event and the payload's action when that event has one; GitHub recommends checking both before processing.[1]
• Follow the same delivery value into the receiver record. Find the linked queue job and inspect whether it is pending, running, finished or terminally rejected under the application's own definitions.
• Follow the job's intended action into the permitted downstream lookup. Match the source scope, target and payload, not just a similar timestamp. Distinguish an accepted operation from a completed result.
• Select the branch below from the combined evidence. If a log is expired, a queue lookup is inaccessible or a provider record cannot be uniquely matched, leave the outcome unresolved. An empty search is not a final no-effect status.

For receiver design, document the boundary between acceptance, durable enqueueing and the 2XX response. Decide what a duplicate receipt returns and how it recovers an existing job. Sending 2XX does not create durability by itself, and recording a delivery as merely 'seen' does not prove that its work was accepted. These are proposed design checks, not guarantees made by GitHub's queue recommendation.

Check authenticity separately from duplicate handling

GitHub says to validate the webhook signature before processing the delivery further. With a configured webhook secret, X-Hub-Signature-256 contains an HMAC-SHA256 signature with the prefix sha256=. Preserve the payload and headers before verification and use a constant-time comparison, not a plain == comparison. If no secret is configured, that signature header will be absent.[3] This guide does not configure a secret or supply a tested receiver adapter.

A valid signature checks the sender and payload integrity. It does not show that this is the first receipt, that the application supports the event/action, or that the intended effect succeeded. Each receipt, including a redelivery, needs the receiver's normal authenticity and applicability checks before business handling. A failed verification also does not settle what an earlier attempt may already have done.

GitHub recommends using X-GitHub-Delivery to identify unique deliveries, and requested redelivery preserves it.[1] Our proposed duplicate-handling check is broader: the application should recognize the same scoped delivery and payload atomically, return or reconcile its existing state, and control downstream repetition where needed. Check retention and provider propagation explicitly. The header alone neither enforces an external provider's idempotency contract nor promises exactly-once work. A receiver that discards every previously seen GUID must also define how an authorized recovery of terminally rejected work can proceed without bypassing its safety checks.

Choose a recovery path from the combined status

A repetition-safety contract must cover this action, source/account scope, payload, concurrent attempts and recovery interval, including an external provider when necessary. Receiver-side message suppression is not enough if a worker can still repeat an external write. This is a proposed standard for accepting that contract, not a capability established by the four GitHub pages.

Before redelivery, confirm that the receiver fault is repaired; signature and event/action handling are ready; any old runnable work is accounted for; and the same delivery can enter the intended recovery path without creating another effect. Check the documented GitHub window and the operator's access for that webhook type. Obtain the actual operator's authorization. The editorial examples here authorize no production action.

Four fictional deliveries, four completed decisions

All identifiers, states and decisions in this section are fictional and unexecuted. D-demo values are short teaching labels standing in for real X-GitHub-Delivery GUIDs; J-demo labels identify jobs and E-demo labels identify external effects. Assume a receiver with signature validation and supported event/action checks, plus authorized status lookups that correlate the exact source, target and payload. The application status semantics stated in each case are assumptions, not standard GitHub fields.

D-demo-3 relies on positive, final no-effect evidence and the absence of possible late work under a stated contract. Removing those assumptions would move it to the unresolved branch. D-demo-2 is a different problem: the job exists, so recovery belongs to the queue and worker rather than another webhook receipt. D-demo-1 still needs a completion check because accepted is not necessarily completed.

Use the redelivery option for the actual webhook type

GitHub does not automatically redeliver failed deliveries. Its guide documents redelivery for deliveries that occurred in the past 3 days.[2][4] That is a GitHub redelivery window, not the retention lifetime of your queue or provider records. An older or missing delivery record does not prove that its action never happened. Investigate repeated delivery failures using their stated failure reason rather than sending the same request indefinitely.[2]

For a repository webhook, the documented UI path is repository Settings → Webhooks → the selected webhook → Recent deliveries → the original delivery GUID → Redeliver.[4] Use it only after the application's recovery decision and the operator's authorization. Requested redelivery keeps X-GitHub-Delivery unchanged.[1] Organization and App webhooks have their own settings paths; do not assume repository-admin access applies to them.

GitHub's failure guide also describes writing scripts to find and redeliver failed deliveries.[2] A script is user-authored automation, not a built-in GitHub retry schedule. This article supplies no API command, credential setup or production script, and neither connects an account nor executes redelivery.

Close the recovery on the work result

After an authorized recovery, read the receiver, queue and downstream records again. Preserve the original delivery identity, the recovery attempt, the existing or new job linkage, the correlated operation result and the reason for the decision. A fresh 2XX closes the acknowledgment question; it does not close unfinished background work. A queued job also needs its own completion or final failure evidence.

• Close as completed only when the intended result is authoritatively correlated to the delivery and payload, with no unresolved work capable of a conflicting duplicate under the integration's contract.
• If the provider has accepted the operation but not completed it, retain its operation identity and the documented next status check. Do not replace it with a second create to make the dashboard look successful.
• If recovery fails again, keep the actual failure reason, the recovery owner and the next permitted check. If the effect remains unknown, retain that uncertainty and the hold rather than reporting success or nonexecution.

The sources establish GitHub's delivery guidance, stable redelivery header, signature handling and documented recovery options. They are four pages from one publisher, not independent runtime corroboration. No receiver, queue, external operation or recovery experiment was run for this guide, and no reliability or business improvement was measured. Use your integration's actual status and duplicate-handling contracts to settle the application decisions.