Skip to content
Use case

Debug and replay GitHub webhooks

Works with GitHub webhook events. When a push or workflow_run delivery hits a 500 and a deploy silently never runs, HookWatch shows what was sent and lets you replay it.

Works with GitHub webhook events. GitHub webhooks — push, pull_request, workflow_run — trigger deploys, checks, and bots. When the receiving endpoint is flaky, a delivery fails and the deploy or check it should have started simply never runs. Nobody gets an error; the work just silently does not happen.

How GitHub deliveries fail

  • Endpoint 500s. A push hits a handler that throws and returns 500; the deploy it should have kicked off never starts.
  • Timeouts. A workflow_run handler blocks on slow work and GitHub gives up before it returns 200.
  • Signature failures. The X-Hub-Signature-256 HMAC check fails and the delivery is rejected with 401.

Debugging the delivery

GitHub’s own "Recent Deliveries" view shows the request, but it lives in the webhook settings and disappears from view fast. Point the webhook at your HookWatch endpoint instead and every delivery is captured with its request and response, kept in one feed across deploys. You can read the exact payload and the failed response, tell a slow handler from a dead one via the attempt timeline, and see repeated failures grouped as an incident.

Replay instead of re-pushing

Once you have fixed the receiver, replay the captured delivery — you do not have to push an empty commit or re-open a PR just to re-trigger the event. This is webhook debugging applied to GitHub; see also how to debug a failed webhook and webhook monitoring. HookWatch works with GitHub events; it is not an official GitHub integration or partnership.

Get started

Start debugging your webhooks.

Point one endpoint at HookWatch, capture a failure, and replay it once it’s fixed. Free during beta.