In Stripe, go to Developers → Webhooks → [endpoint] → Recent Deliveries → [failed event] → Resend. In Shopify, navigate to Settings → Notifications → [webhook] and manually retrigger. In GitHub, go to Settings → Webhooks → Recent Deliveries → [delivery ID] → Redeliver. Or use a monitoring tool that surfaces a replay link directly in the failure alert.

How to Replay a Failed Webhook: Stripe, Shopify, and GitHub

May 20, 2026 · 6 min read · Webhook best practices

A webhook fails. Your handler was down during a deploy, or a bug crept in, or your database was briefly unreachable. The event was never processed. Now you need to replay it — get the original payload back to your endpoint so your system state catches up with reality.

Each platform handles this differently. Stripe has a clean redeliver button. Shopify is more limited. GitHub has a redeliver option buried in the delivery log. And if you're using a webhook monitoring tool, you may not need to visit any of these dashboards at all.

How do you replay a failed Stripe webhook?

Stripe has the best built-in replay experience of the three platforms. Here's the exact path:

1. Go to Stripe Dashboard → Developers → Webhooks
2. Click your endpoint URL
3. Under Recent Deliveries, find the failed event (filter by status: Failed)
4. Click the event row to expand it
5. Click Resend

Stripe immediately attempts a new delivery of the same event object to your endpoint. The redelivered event has the same event ID (e.g. evt_1abc...) — it is not a new event. The delivery timestamp will update, but the event data is identical to the original.

This means your handler must be idempotent before you replay. If you didn't store the event ID in a processed_events table after the original attempt, replaying will re-run all your business logic — which may be exactly what you want, or may cause a duplicate charge or email.

You can also programmatically trigger a redeliver using the Stripe API by POSTing to the event's delivery endpoint. Webhook Guardian includes a one-click replay link in every Slack and email alert, so you can trigger the redeliver without ever visiting the Stripe Dashboard.

How do you replay a failed Shopify webhook?

Shopify's replay story is more limited than Stripe's. There is no native "redeliver this specific failed event" button in the Shopify admin for production events.

What Shopify does offer:

• Send test notification: In Settings → Notifications → Webhooks → [webhook], there is a "Send test notification" button. This sends a synthetic test payload to your endpoint — not the original failed event data. Useful for verifying connectivity, not for recovering a real failed event.
• Re-trigger the source action: If an orders/paid webhook failed, you can't replay the original event — but you can sometimes re-trigger the underlying action. For example, updating the order status to fire an orders/updated event. This only works if your handler logic accepts that event type as a substitute.
• Shopify Admin API: You can query GET /admin/api/2024-01/events.json to fetch shop events and reconstruct the payload, then POST it manually to your endpoint. This requires custom tooling.

Webhook Guardian stores the original payload from every Shopify delivery attempt we've seen. If we detected a failure, the alert includes a replay button that POSTs the stored payload back to your endpoint — solving the "no native redeliver" limitation.

How do you replay a failed GitHub webhook delivery?

GitHub has a clean redeliver option, though it's buried a few levels deep in the repository settings:

1. Go to your repository → Settings → Webhooks
2. Click the webhook URL
3. Click the Recent Deliveries tab
4. Find the failed delivery by its GUID (e.g. 72d3162e-cc78-11e3-81ab-4c9367dc0958)
5. Click the delivery row, then click Redeliver

GitHub retransmits the original payload and all original headers exactly as they were — including the X-Hub-Signature-256 HMAC signature (computed with your secret at the time of the original delivery) and the original X-GitHub-Delivery UUID. Your endpoint will see the exact same request it saw the first time.

For organization-level webhooks, the path is Organization Settings → Webhooks rather than the repository settings.

You can also redeliver programmatically using the GitHub API:

# GitHub API: redeliver a specific webhook delivery
POST /repos/{owner}/{repo}/hooks/{hook_id}/deliveries/{delivery_id}/attempts

# Example with curl:
curl -X POST \
  -H "Authorization: Bearer {YOUR_GITHUB_TOKEN}" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/acme/app/hooks/12345/deliveries/67890/attempts

What should you do before replaying any webhook?

Replaying without fixing the root cause will fail again. Before hitting that redeliver button:

1. Identify why it failed. Check your server logs for the time of the original delivery. Was it a 500 (application error)? A 503 (server down)? A signature verification failure? A timeout?
2. Fix the underlying issue. Deploy the fix, bring the server back up, correct the environment variable, or restore the database connection.
3. Verify your handler is idempotent. If the original event was partially processed (e.g. the database insert succeeded but the email send failed), a full replay might cause a duplicate database row. Review your idempotency implementation before replaying.
4. Replay and verify. After redelivery, check your server logs to confirm a 200 response and verify the expected side effects occurred (record created, email sent, subscription updated).

Why is one-click replay from a monitoring alert faster?

The manual replay workflow for each platform requires navigating 3–5 screens, finding the correct delivery in a list, and clicking through a confirmation. If you're monitoring 3 platforms with multiple webhooks each, that's a lot of context-switching during an incident.

Webhook Guardian includes a replay link in every failure alert — whether delivered to Slack or email. The link pre-authorizes the redeliver action so you can trigger it in one click without logging into the platform dashboard. You get:

• The event type and payload preview in the alert itself
• The delivery attempt history (which retries failed and when)
• A one-click redeliver button that fires the replay immediately
• Confirmation when the replay delivery succeeds or fails

Mean time to replay goes from 5–10 minutes of dashboard navigation to under 30 seconds from alert receipt.

FAQ: Replaying failed webhooks

Get alerted the moment a webhook fails — with a one-click replay link. Webhook Guardian monitors Stripe, Shopify, and GitHub and surfaces replay controls directly in your Slack alert. Start free for 14 days →

Also read: Webhook reliability best practices · Webhook idempotency guide · Stripe monitoring · Shopify monitoring · GitHub monitoring