GitHub webhook delivery logs are stored at Settings → Webhooks → [webhook] → Recent Deliveries for 72 hours. Each entry shows the event type, delivery UUID, HTTP response code, response headers, and response body. GitHub does not alert you when a delivery fails — you have to monitor the log yourself or use a tool that polls the GitHub API every few minutes.

GitHub Webhook Delivery Logs: What They Show and What They Miss

May 20, 2026 · 5 min read · GitHub monitoring

Your CI pipeline stopped triggering on push events. The GitHub webhook is still configured, still listed as active, and still showing a green checkmark in settings. But deliveries have been failing for two days — silently, with no alert, while your team pushed code assuming CI was running.

GitHub's webhook delivery log has the full failure record. The problem is that GitHub never told you to look.

Where are GitHub webhook delivery logs?

Delivery logs live inside each webhook's settings page:

• Repository webhooks: [repo] → Settings → Webhooks → [webhook] → Recent Deliveries
• Organization webhooks: [org] → Settings → Webhooks → [webhook] → Recent Deliveries
• GitHub App webhooks: Settings (personal) → Developer Settings → GitHub Apps → [app] → Advanced → Recent Deliveries

GitHub retains delivery logs for 72 hours. After that, records are no longer accessible via the dashboard or API.

What does a GitHub webhook delivery log contain?

Each delivery entry shows:

• Event type — e.g. push, pull_request, workflow_run
• Delivery UUID — unique identifier for this specific delivery attempt
• Response code — the HTTP status code your endpoint returned
• Response headers — headers returned by your endpoint
• Response body — the full body your endpoint returned
• Request payload — the full JSON payload GitHub sent
• Timestamp — when the delivery was attempted
• Duration — how long GitHub waited for a response
• Redelivery button — re-send this specific delivery to your endpoint

The delivery UUID is particularly useful — it lets you trace a specific event through your own logs to see exactly what your handler received and how it responded.

What does a failed GitHub webhook delivery look like?

A failed delivery shows a red indicator and a non-2xx response code. Common failure patterns:

# Failure: endpoint timeout (no response within 10 seconds)
status: Failed · duration: 10001ms · response: N/A

# Failure: endpoint returned error
status: Failed · response: 500 Internal Server Error

# Failure: connection refused
status: Failed · response: N/A · error: connect ECONNREFUSED

GitHub does not retry failed webhook deliveries automatically. Each failed delivery is logged, and you can manually redeliver it — but GitHub will not attempt it again on its own.

Does GitHub alert you when a webhook delivery fails?

No. This is the critical gap. GitHub logs every delivery — succeeded or failed — but sends no alert when a failure occurs. There is no email, no notification in the GitHub UI, no API push event for failed deliveries. You find out only when you check the delivery log manually, or when you notice the downstream effect (CI stopped running, deployment stopped triggering, automation broke).

This is fundamentally different from how Stripe handles webhook failures (which at least sends an email after exhausting retries). GitHub simply records the failure and moves on.

How can you access GitHub webhook delivery logs via the API?

GitHub exposes delivery history through the REST API:

# List deliveries for a repository webhook
GET /repos/{owner}/{repo}/hooks/{hook_id}/deliveries
Authorization: Bearer {token}   # requires repo + admin:repo_hook scope

# Get a specific delivery
GET /repos/{owner}/{repo}/hooks/{hook_id}/deliveries/{delivery_id}

# Redeliver a specific delivery
POST /repos/{owner}/{repo}/hooks/{hook_id}/deliveries/{delivery_id}/attempts

Organization webhooks use the same pattern under /orgs/{org}/hooks/{hook_id}/deliveries.

This is the API that monitoring tools poll to detect failures without you having to check the dashboard.

What does GitHub's delivery log miss?

The delivery log is comprehensive within its 72-hour window — but it has two significant gaps:

• No active alerting — the log is passive. GitHub records what happened but does not push any notification on failure. You have to pull the log to find out.
• 72-hour retention — if you check once a week, failures from the first four days of the week are gone. You can only see what happened in the last 3 days.

Both gaps are closed by polling the delivery log frequently — every 5 minutes guarantees you catch failures well within the retention window, and you can alert on them in near real-time.

Which GitHub webhook events are most critical to monitor?

The highest-impact failures to catch:

• push — CI triggers, deployment pipelines, code sync automations. A missed push event means CI doesn't run and the deploy queue stalls silently.
• pull_request — review bots, status checks, automated label workflows. Missed events break the PR automation layer.
• workflow_run — downstream automation that depends on CI completion signals. Missed events break release pipelines.
• deployment and deployment_status — environment tracking, release management systems. Missed events leave environments in unknown state.
• create / delete — branch or tag lifecycle events. Missed events break branch protection automations.

FAQ: GitHub webhook delivery logs

Monitor GitHub webhook failures automatically. Connect GitHub to Webhook Guardian and get alerted within 5 minutes when a push, pull_request, or deployment event fails to deliver — with the delivery UUID, error, and a one-click redeliver link. Start free for 14 days →