Skip to main content

​
Inspect deliveries and replay failures

Your webhook endpoint’s behavior is not always deterministic — a deploy, a bad deploy rollback, a provider timeout. The webhook delivery tooling answers the two questions that matter when something goes wrong: what did Orbit actually send? and how do I get the events my endpoint missed? Three surfaces cover the loop. Use them in order: the Events explorer watches live traffic, the delivery inspector dissects one delivery, and manual replay re-sends the failures after your endpoint recovers.

​
Explore events across your endpoints

Open Developer → Webhooks → Events in the dashboard. This timeline lists every delivery attempt across all of your webhook endpoints, most recent first, regardless of which endpoint the delivery targeted. Narrow the timeline with the filters along the top:
  • Status — success, failed, or pending (queued or mid-retry).
  • Endpoint — pivot to a single endpoint once you know which integration is misbehaving.
  • Search — substring match on the event type, so message isolates the whole messaging family and delivered narrows to delivery confirmations.
  • Time range — bound the window with from_date / to_date parameters on the underlying API.
The same data is available over the API when you want to script it:
The response is cursor-paginated; follow pagination.cursor in each page’s response to walk backward through the window.

​
Reliability roll-up

Next to the timeline, the reliability sidebar summarizes every endpoint across the last 24 hours: success rate, p95 latency, the age of the oldest still-pending delivery, and the most recent event. A stuck or degrading endpoint surfaces here before customers notice. Fetch the same roll-up programmatically:
window_hours accepts 1–168 (one hour to one week).

​
Inspect a single delivery

Click Details on any row to open the delivery inspector for that attempt. The slide-over shows exactly what left Orbit and what your server returned, for that one attempt:
  • Request payload — the JSON envelope your endpoint received, pretty-printed.
  • Request headers — including the signature headers, so you can verify a signature reproduction case by hand.
  • Response status, headers, and body — what your server answered (or the timeout note when it did not).
  • Delivery ID and Event ID — the correlation identifiers to quote when asking support about a specific failure.
  • Retry history — every attempt in this event’s retry chain, oldest first, each with its own HTTP code and timestamp. Spot the difference between “flapping” and “consistently failing with the same 403.”
Every identifier carries a copy button, and a one-click Copy diagnostics bundles the whole delivery (ids, timestamps, status, error text) into the clipboard — formatted so you can paste it directly into a support ticket.

​
Replay a failed delivery

Once the underlying problem is fixed — the endpoint is back up, the signature secret is re-synced, the firewall allowlist covers our egress IPs — re-drive the failed events with Replay. Replay is scoped tightly so it cannot surprise you:
  • Failed rows only. A successful delivery has no Replay action — re-sending an event your receiver already processed would double-fire billable downstream effects.
  • This endpoint only. Replay re-sends to the endpoint the original failed on. It does not fan out to other endpoints subscribed to the same event.
  • Within 7 days. Deliveries older than the 7-day retention window are not eligible. Past that point, use the time-range replay below to backfill explicitly.
Replay queues immediately. The original attempt’s history is preserved as the audit record; the new attempt appears as a fresh delivery row, and its outcome lands back in the Events timeline within seconds. Each replay is recorded in your audit log alongside the operator who triggered it. The equivalent single-delivery API call:
The response returns 202 Accepted with a replay_event_id you can poll against the deliveries listing to see the new attempt’s outcome. If the delivery is not eligible, the response tells you why: a non-failed delivery returns 409, and one past the retention window returns 422 with the timestamp the eligibility lapsed at.

​
Replay many at once

Two bulk paths cover larger outages:
  • Dead-letter queue — Developer → Webhooks → Dead-letter queue lists deliveries whose retries are fully exhausted. Filter by event type or failure reason, select the rows for the incident, and use Replay (or POST /webhooks/dlq/bulk-replay for up to 200 rows in one API request) to put them back into the retry pipeline.
  • Time-range replay — for a whole outage window on one endpoint, use POST /webhooks/:id/replay-range with explicit from / to bounds. Send dry_run: true first to preview the count before confirming; the dashboard’s bulk-replay flow runs the same preview under the hood.
Both bulk paths report per-row outcomes, so a row that recovered on its own (or a concurrent operator already handled) shows as skipped rather than silently re-firing.

​
What to check when deliveries keep failing

  • Signature failures — compare the signing secret on the endpoint’s page against what your verifier uses; the signature troubleshooting guide walks the common mismatch cases.
  • Timeouts — respond within 30 seconds; if you need longer to process, ack the delivery and process asynchronously.
  • Proven-dead statuses — 401, 403, 404, and 410 disable the endpoint immediately. Re-enable it from the dashboard once the auth or path issue is fixed.
  • Egress allowlists — if your firewall filters inbound, allowlist Orbit’s published egress IPs (listed on the endpoint page and via GET /webhooks/egress-ips).