GitHub webhooks
Test and debug GitHub webhooksfor CI/CD, bots and releases
Code reviews, deployment pipelines and chatops depend on GitHub webhooks. Hooklistener captures every push, pull_request and check_run payload and checks its signature against your secret.
How GitHub webhooks work
| Signature header | X-Hub-Signature-256: sha256= followed by the HMAC-SHA256 hex digest of the payload, keyed with the webhook secret. |
|---|---|
| Timeout | Respond with a 2XX within 10 seconds, or GitHub terminates the connection and counts the delivery as failed. |
| Retries | None. GitHub does not automatically redeliver failed deliveries. |
| Manual redelivery | Recent deliveries lists the past 3 days; open a delivery GUID and click Redeliver (or use the REST API). |
| Delivery ID | X-GitHub-Delivery is unique per delivery; GitHub suggests it for spotting replayed requests. |
Sources (checked November 2026)
Stop chasing flaky GitHub integrations
GitHub webhooks fuel deployment gates, changelog bots and code analytics. Hooklistener stores each payload with its headers so you can prove exactly what GitHub sent.
Replay events into local services or staging pipelines whenever you change logic, instead of pushing dummy commits or opening throwaway PRs. Replay is on Pro and above.
When a GitHub webhook isn't reaching your server, GitHub's Recent Deliveries log shows whether the event was sent, whether the connection failed or timed out after 10 seconds, or which status your server returned. Pair it with a Hooklistener endpoint or tunnel to see the exact request on your side.
Common GitHub webhook headaches
Hidden delivery failures
GitHub shows a 500 but your logs do not show the request. You need the raw JSON and headers to fix the endpoint quickly.
Signature verification
A misconfigured secret breaks verification. You need to compare the X-Hub-Signature-256 header with what your HMAC code computes.
Difficult replays
Re-running a failed pipeline should not require rewriting history or pushing another commit.
How Hooklistener helps with GitHub webhooks
GitHub signature verification
Store your GitHub webhook secret (paid plans) and Hooklistener checks X-Hub-Signature-256 on each captured delivery, so a mismatched secret shows up before your handler starts rejecting pushes.
Replay (Pro) a push or release event
Resend a captured GitHub push or release payload to localhost, staging or production to re-run a failed pipeline without a dummy commit.
Diff two GitHub deliveries
Compare the JSON of two GitHub deliveries, and let anomaly detection flag new event types or missing fields after you install a GitHub App or change the webhook's events.
Try it: point GitHub at a free webhook URL or run a test with the webhook tester.
GitHub webhook automations to harden
CI/CD orchestration
Replay (Pro) push events to pipelines when builds misfire and check check_suite updates before merging.
Release communications
Send release and deployment events into Slack or Teams and confirm the payload structure first.
Change history
Keep recent webhook deliveries for a repository so you can trace which event triggered which automation.
Replay a failed webhook without re-triggering the provider
Once a delivery is captured, you can resend its exact headers and body to localhost, staging or production from the dashboard or through your coding agent over MCP, so the provider never has to fire a new event. Replay is on Pro and above. Read the replay guide.
GitHub webhook guides
Debug a GitHub webhook that isn't reaching your server
Work from Recent Deliveries through connection errors, timeouts, 4xx/5xx, X-Hub-Signature-256 mismatches and tunnel checks.
GitHub webhooks on localhost
Run hooklistener tunnel --port 3000, set the Payload URL, verify signatures and redeliver while you build.
Comparing webhook debugging tools?
See how Hooklistener stacks up against webhook.site, RequestBin, Beeceptor, Hookdeck and ngrok in the best tools to capture and inspect webhook payloads, or read the head-to-head pages for Hooklistener vs ngrok and Hooklistener vs Beeceptor.
Frequently asked questions
Why is my GitHub webhook not reaching my server?
Open the webhook's Recent Deliveries in GitHub. If a newly triggered event is missing, check the selected events, Active checkbox and repository; deliveries older than three days are no longer listed. A connection error or timeout means GitHub couldn't reach the Payload URL or got no response within 10 seconds. A 4xx or 5xx means your app or a proxy in front of it returned an error, often because of a wrong path, an X-Hub-Signature-256 mismatch or an unreachable upstream (502/503/504).
How do I receive GitHub webhooks on localhost?
GitHub can't call localhost directly. Run hooklistener tunnel --port 3000 and use the printed HTTPS URL plus your route as the Payload URL. Deliveries are forwarded to your local server and its response is returned to GitHub.
Can Hooklistener send one GitHub webhook to several services?
Yes. Auto-forwarding (Pro) copies each captured delivery to another URL, and Production lifts the limit on forwarding destinations, so the same event can reach your CI service and a bot.
How long are payloads stored?
History depends on your plan: 1 day on Free, 14 days on Pro, 30 days on Production and 90 days on Scale.
Can I diff payloads over time?
Yes. Compare two webhook deliveries to highlight new or removed fields before they break downstream services.
Give your GitHub automations a safety net
Capture GitHub webhooks with Hooklistener, verify their signatures and replay (Pro) an event when a pipeline fails.