Skip to main content

​
Triage webhooks across every endpoint: the Events timeline

The Developer → Webhooks → Events page is a tenant-scoped dispatch timeline that lists every webhook dispatch attempt across all of your endpoints in chronological order, with per-endpoint reliability stats and one-click replay of failed deliveries. Use it when you do not yet know which endpoint is failing — it answers “what broke, and where?” in one screen.

​
1. Events timeline vs per-endpoint page — which to open

There are two delivery surfaces, and they answer different questions. The per-endpoint page is where you operate one endpoint: health panel, retrying state, secret rotation, bulk replay by range. The Events timeline is where you triage across endpoints before drilling into one. A typical incident flow: notice failures on the timeline, filter to the offending endpoint, then open its detail page for rotation, bulk replay, or test-fire.

​
2. Filters

Four filters narrow the timeline; they combine (AND), and the result set resets with a clean cursor whenever any filter changes.
  • Status — all, success, failed, or pending (a delivery still inside the automatic retry pipeline).
  • Endpoint — one of your configured endpoints, or all. The dropdown lists every endpoint you have, including ones with no deliveries in the window.
  • Event type search — free text matched against the event type, so message catches message.sent, message.delivered, and so on. Debounced 300 ms.
  • Date range — dispatch-time window. The end of the range is pinned to end-of-day, so a same-day start→end selection returns that day rather than an empty window.
A Slow treatment applies on top of the row data rather than as a filter: a successfully delivered row whose latency crosses the slow threshold is flagged amber, and the column header states the threshold (half the platform delivery timeout, so 15 s against the 30 s default). On the per-endpoint Deliveries table a slow row is flagged against that endpoint’s own configured timeout instead. When no rows match, the empty state tells you whether the window is genuinely empty or your filters matched nothing, with a one-click clear.

​
3. Per-endpoint reliability cards

The card strip above the timeline rolls each endpoint up over the trailing 24 hours:
  • Success rate — the share of terminal deliveries (succeeded + failed) that returned 2xx. An endpoint whose deliveries are all still in flight shows idle rather than a misleading 100 %.
  • Attempts — total dispatch attempts in the window, including retries still running.
  • p95 latency — receiver response time at the 95th percentile.
  • Oldest pending (all time) — the timestamp of the oldest delivery still in the retry pipeline. This is the number you read when an endpoint backs up: a delivery pending for hours with a climbing attempt count means your receiver is consistently failing, not just slow on one request.
The badge colours run green (≥ 99 %), amber (90–98.9 %), red (below 90 %), on the same thresholds as the per-endpoint health panel.

​
4. Replay a delivery

Every row — success, pending, or failed — opens a Details inspector with the sanitized payload, request and response headers, the response status and body, the error text, and the copyable diagnostic identifiers (delivery id, correlation event id, attempt history, timestamps). Replay appears only on failed rows. Clicking it re-POSTs the stored original payload to the endpoint, signed with the endpoint’s current secret. The contract:
  • Replay is a failure-recovery action. Successful and pending rows have no Replay control, and single-row replay rejects a non-failed status with 409 — successful re-delivery flows through bulk replay by range with a dry-run preview, not a silent double-fire.
  • Replay is idempotent at the receiver if your consumer is: the re-delivered event carries the same event id, so the standard duplicate-event dedupe covered in Build a durable webhook consumer applies. A replay re-attempts delivery; it never invents a new event.
  • Deliveries older than the 7-day replay retention window cannot be single-row replayed. To backfill older events, use the per-endpoint replay-range flow with an explicit time window.
For a large backlog, prefer the per-endpoint replay by range dialog — its dry-run preview counts matched deliveries before you commit, and the job drives them with bounded concurrency.

​
5. Failure categories vocabulary

Every failed delivery carries a failure_category chip so the timeline is self-diagnosing at a glance, without opening the raw response: A 5xx or a timeout retry automatically; a 4xx means the failure is deterministic and no amount of retrying will succeed, so the chip tells you to fix then replay.

​
See also