Skip to content
Telemetry
For teams that depend on Stripe, GitHub, customer, or provider webhooks

Webhook debugging

Track webhook delivery, processing, retries, deduplication, downstream jobs, and failures without storing raw payloads.

Reviewed by the Telemetry product team on . We checked the event fields, suggested queries, and data to exclude. Who reviews this page

Why this works
  • See failures by provider, event type, endpoint, and downstream job.
  • Measure retry and duplicate rates from real webhook processing events.
  • Keep a history of webhook outcomes so you can investigate billing and integration failures.
How to test this use case

Measure Webhook debugging and check the results

To measure webhook debugging, choose one workflow and its owner. Define the events, test them with known inputs, and write a query that answers a specific question.

  1. 1

    Choose when to log

    Log webhook_received, webhook_processed, webhook_failed, and webhook_retried.

  2. 2

    Capture the outcome

    Begin with webhook_received, webhook_processed, webhook_failed and document the grain of each event.

  3. 3

    Check the stored rows

    Create alerts for repeated failures, retry spikes, and processing latency.

  4. 4

    Make the decision

    Which webhook event types fail most often?

Use case versus template

Choose what to measure

Use this guide to choose what to measure and when to log it. For a shorter setup prompt, open the matching template.

Open Webhook debugging template

Agent prompt

Paste this into your coding agent

Replace YOUR_API_KEY after signup, then ask the agent to run the product flow and verify the first events.

agent prompt

Webhook debugging setup prompt

text
Instrument webhook debugging with Telemetry.

Use /skill.md and this Telemetry API key: YOUR_API_KEY

Please log webhook_received, webhook_processed, webhook_failed, webhook_retried, and webhook_deduplicated. Include provider, event_type, route_template, status, status_code, latency_ms, attempt, idempotency_outcome, downstream_job_count, team_id, and error_type.

Create queries for volume by provider, failures by event type, retry rate, duplicate rate, p95 processing time, and latest failed webhooks.

Do not log raw webhook bodies, signatures, secrets, payment details, or personal data.

Setup steps

  1. 1Log webhook_received, webhook_processed, webhook_failed, and webhook_retried.
  2. 2Capture provider, event type, status, latency, attempt, and idempotency outcome.
  3. 3Connect downstream jobs or billing syncs triggered by each webhook.
  4. 4Create alerts for repeated failures, retry spikes, and processing latency.

Events to capture

webhook_receivedwebhook_processedwebhook_failedwebhook_retriedwebhook_deduplicatedbilling_sync_failed

Questions you can answer

  • Which webhook event types fail most often?
  • Are retries fixing failures or creating duplicates?
  • Which downstream systems are affected by provider delays?

Example event schemas

Check what each event records, when to send it, and which field types it needs. Review the example payload and privacy checklist before using it in production.

Use these queries in Telemetry

Learn about Alerts

Add a threshold and recipients to your reliability query to get alerts.

Related SQL recipes

More SQL recipes

Run the query using this workflow's event fields and check the example result. Save the result to a dashboard or set up an alert.

Browse all recipes
Recipe collectionsWebhooks SQL

Customer evidence

Related customer stories

Next step

Create the API key your agent will use

The free plan is enough to run the prompt, send test events, and review the first dashboard.

Related pages