Event contract
Fields the query expects
| Field | Type | Why it exists |
|---|---|---|
| timestamp_utc | Timestamp | Processing completion time. |
| provider | Utf8 | Webhook provider. |
| event_type | Utf8 | Provider event category. |
| idempotency_outcome | Utf8 | new_event or duplicate. |
| status | Utf8 | success or failed. |
| latency_ms | Float64 | Processing duration. |
Copy the query
SELECT
provider,
event_type,
COUNT(*) AS deliveries,
SUM(CASE WHEN idempotency_outcome = 'duplicate' THEN 1 ELSE 0 END) AS duplicates,
SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) AS failures,
100.0 * SUM(CASE WHEN idempotency_outcome = 'duplicate' THEN 1 ELSE 0 END)
/ NULLIF(COUNT(*), 0) AS duplicate_rate_pct,
approx_percentile_cont(latency_ms, 0.95) AS p95_latency_ms
FROM webhook_deliveries
WHERE timestamp_utc >= now() - INTERVAL '7 days'
GROUP BY provider, event_type
ORDER BY duplicate_rate_pct DESC, failures DESC;This read-only query is planned and executed against an empty typed table with Apache DataFusion 45.2.0. The deterministic sample output is synthetic and reviewed separately; validate field types, thresholds, and business definitions against your own data. Read the testing methodology.
Query result
Duplicate and failed webhook deliveries
Stripe payment failures have the highest duplicate rate and more terminal failures.
| provider | event_type | deliveries | duplicates | failures | duplicate_rate_pct | p95_latency_ms |
|---|---|---|---|---|---|---|
| stripe | invoice.payment_failed | 480 | 34 | 9 | 7.08 | 1,180 |
| github | push | 2,940 | 42 | 3 | 1.43 | 420 |
Synthetic example output. Run the query against your own event schema and thresholds before using it for operational decisions.
Reproduce the example
Download the public fixture
The JSON bundle includes the typed event contract, illustrative input rows, exact SQL, expected output, review notes, and engine version. The CSV contains the displayed result.
How the SQL works
- 1CASE expressions compute duplicate and failure counts from the same delivery population.
- 2The duplicate rate is a delivery characteristic; it does not prove duplicate business effects.
- 3Tail latency shows whether the handler is approaching a provider timeout or retry boundary.
Edge cases to decide
- A duplicate may be successfully deduplicated and should not automatically count as failure.
- Provider retry policies and event volumes differ, so preserve provider and event type.
- Never store webhook signatures or raw payment payloads in this table.
Recommended dashboard
- Stacked bars: duplicates and failures by event type
- Trend: p95 webhook latency
- Table: recent failed downstream jobs
Alert guidance
Alert on repeated processing failures or duplicate side effects, not expected deduplicated delivery.
Read alert setupPut the recipe to work
Related instrumentation and guides
Continue the analysis
Measure Webhook Retry Recovery
Separate permanent webhook failures from deliveries that recovered on a later attempt.
Open recipeMeasure Webhook End-to-End Completion
Follow each webhook from receipt through downstream completion and measure the share that finishes within an operating target.
Open recipeRun it on real events
Create a table, adapt the fields, and save the result
Start free, send structured events, and use the query result as a chart, shared dashboard widget, or alert input.