Skip to content

feat: add Webhook Deliveries query type - #798

Open
KyriosGN0 wants to merge 1 commit into
grafana:mainfrom
KyriosGN0:feat/webhook-deliveries
Open

feat: add Webhook Deliveries query type#798
KyriosGN0 wants to merge 1 commit into
grafana:mainfrom
KyriosGN0:feat/webhook-deliveries

Conversation

@KyriosGN0

Copy link
Copy Markdown

What

  • Adds a Webhook Deliveries query type that lists deliveries of an organization or repository webhook, one row per delivery: delivered_at, event, action, status, status_code, duration, redelivery, repository_id, installation_id, and a derived success boolean.
  • Query options: hook ID (required), event filter, and a status filter (All / Success / Failure). Leaving the repository empty queries an organization webhook; setting it queries that repository's webhook.
  • Wraps Organizations.ListHookDeliveries and Repositories.ListHookDeliveries from go-github, alongside the existing REST-backed query types.
  • Documents the query type in docs/sources/query-editor.md, including the required admin:org_hook / admin:repo_hook token scope and GitHub's 3-day delivery retention.

Why

  • Closes Monitor GitHub Webhook Delivery Failures & Success Rates #488. Teams that rely on webhooks for automation currently have no way to notice when delivery silently starts failing. One row per delivery lets a dashboard compute success rates, chart failures over time, and alert on a failure threshold with ordinary transformations, so no separate aggregation query type is needed.

Notes for reviewers

  • The deliveries endpoint has no server-side time filter and is cursor paginated, so the query pages from the most recent delivery until it reaches the start of the time range, capped at 50 pages (5000 deliveries) to protect the rate limit. Results that do not cover the whole time range carry a warning notice on the frame, either because that cap was reached or because GitHub ran out of deliveries within its 3-day retention window — a silently short window would understate failure counts.
  • Because paging always starts at the most recent delivery, a time range that ends in the past still pages through everything that happened since. The API offers no way to avoid this.
  • Deliveries include repository_id but no repository name; resolving names would cost an extra request per repository, so the ID is emitted as-is and documented.
  • Deliveries that never got a response (timeout, DNS) have no status code and count as failures.

🤖 Generated with Claude Code

@KyriosGN0
KyriosGN0 requested a review from a team as a code owner August 16, 2026 05:57
@github-actions

github-actions Bot commented Aug 16, 2026

Copy link
Copy Markdown
Contributor

Signed commits report

All 1 commit between main and feat/webhook-deliveries have verified signatures. ✅

@cla-assistant

cla-assistant Bot commented Aug 16, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@KyriosGN0
KyriosGN0 force-pushed the feat/webhook-deliveries branch 2 times, most recently from a64450e to 7c6a649 Compare August 28, 2026 08:33
Lists deliveries of an organization or repository webhook, one row per
delivery, so dashboards can track webhook success rates and failures.

The deliveries endpoint has no time filter and is cursor paginated, so
the query pages from the most recent delivery until it reaches the start
of the time range, capped at 5000 deliveries. Results that do not cover
the whole time range, either because of that cap or because of GitHub's
3-day retention window, carry a warning notice on the frame.

Closes grafana#488

Signed-off-by: Aviv Guiser <avivguiser@gmail.com>
@KyriosGN0
KyriosGN0 force-pushed the feat/webhook-deliveries branch from 7c6a649 to 39e2b74 Compare August 28, 2026 08:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Monitor GitHub Webhook Delivery Failures & Success Rates

1 participant