> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Triage webhooks across every endpoint: the Events timeline > Use the Developer → Webhooks → Events page to see dispatch attempts across all your endpoints in one tenant-scoped timeline, filter by status, endpoint, event type, and date, read per-endpoint reliability, and replay a failed delivery in one click. # 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. | Question | Open | | ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | "Did anything fail in the last hour, on any endpoint?" | **Events timeline** | | "Is endpoint X rejecting, and why?" | The **per-endpoint detail page** ([Operate a webhook endpoint](/guides/webhook-endpoint-operations)) | | "Receiver had an outage — which deliveries need replay?" | **Events timeline** — filter status to `failed` | | "Rotate the secret, pause, or test-fire a specific endpoint?" | The per-endpoint detail page | 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](/guides/webhook-endpoint-operations) 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](/guides/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](/guides/webhook-endpoint-operations) 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: | Category | Meaning | | -------------------- | ----------------------------------------------------------------------------------------------------------------------- | | `dns_failure` | The endpoint hostname could not be resolved — check the domain and its DNS records. | | `tls_error` | TLS handshake failed — expired, self-signed, or hostname-mismatched certificate. | | `connection_refused` | The server actively refused the connection — the port is closed or the service is not listening. | | `connection_reset` | The connection dropped before a response completed — often a proxy or load balancer closing the socket early. | | `timeout` | No response within the delivery timeout — return 2xx quickly and do slow work asynchronously. | | `host_unreachable` | No network route to the endpoint host — check firewall rules. | | `ip_blocked` | The endpoint resolved to a private, loopback, or otherwise disallowed address — use a public HTTPS URL. | | `rate_limited` | The endpoint returned `429`. Deliveries back off and retry automatically. | | `server_error` | The endpoint returned `5xx` — inspect your handler's logs; deliveries retry automatically. | | `client_error` | The endpoint returned `4xx` (auth, routing, or validation). 4xx responses are not retried — fix the handler and replay. | | `redirect` | The endpoint returned a redirect, which webhooks do not follow — point the endpoint at its final URL. | | `invalid_response` | The response could not be parsed as expected — inspect the raw body. | | `unknown` | Not categorizable — open the delivery details to inspect 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 * [Operate a webhook endpoint](/guides/webhook-endpoint-operations) — the per-endpoint surface: health panel, secret rotation, test-fire, bulk replay by range * [Webhook event catalog](/guides/webhook-event-catalog) — the event contracts behind each `event_type` the timeline lists * [Build a durable webhook consumer](/guides/webhook-consumer) — idempotent handling and duplicate-event dedupe for replayed deliveries