ShellOrbit / Webhooks
The pipeline under every alert.
ShellOrbit's event pipeline carries your webhooks and every Leak Alarm signal: how events are accepted, delivered, retried, and kept as evidence.
One pipeline for webhooks and leak signals
Provider webhooks, tripwire hits, and scan findings enter ShellOrbit the same way. Each is stored before it is acknowledged, delivered to your destinations with retries, and kept for replay until your plan’s retention ends. That is why a tripwire alert can also reach your own handler, and why a finding from last week is still in your event log. Leak Alarm signals join this pipeline as each part of Leak Alarm opens.
Acceptance and delivery
Acceptance stores the event, usage record, and pending dispatch work together. A scheduled worker revisits pending work if a queue send fails, or if an endpoint was paused or had no destination.
A successful acceptance response means the event entered this process. It does not mean your application has received or processed it yet.
Retries and circuit probes
Retryable failures follow your endpoint’s backoff policy. Each destination has its own delivery attempts. Repeated exhausted failures open a destination circuit; controlled probes check whether it has recovered.
Retry policies are bounded by both their configured attempts and the event’s retention window. A payload cannot be retried after it expires.
Guided recovery
Prepare a preview from failed events within a time window. The selection is saved before recovery starts. Each event–destination pair counts as one delivery. Test up to five selected deliveries, inspect their results, and continue when ready. A failed or unavailable delivery stops further recovery work, with an explicit reason for expired events or removed destinations. Cancellation stops pending recovery work; an HTTP request already in flight may finish.
Recovery jobs have a 24-hour deadline from creation, including time spent preparing or waiting for approval. A stalled or paused job stops at that deadline; prepare a new preview for remaining work. Job history lasts 30 days and does not extend the original event’s payload retention.
Recovery schedules delivery in batches. The chosen rate controls spacing within a batch; it is not guaranteed throughput or a global destination rate limit. Automatic retries and destination timing can change the actual request rate.
At-least-once delivery
A destination can finish processing an event just before a connection fails. In that case, a retry may deliver the same event again. Use an event identifier and an idempotent application handler to prevent duplicate business actions.
ShellOrbit does not promise exactly-once execution or global ordering. Manual replay can intentionally repeat an already-delivered event.
Quotas and retention
Plans retain events for 15, 30, 60, or 180 days. Paid plans meter overage; safety limits can still reject new requests with HTTP 429. Provider retry behavior varies. For example, GitHub does not automatically redeliver failed webhooks.
A bookmark does not extend event retention. A separately saved fixture has the expiry you explicitly choose.
Visibility and commitments
Read system status, inspect your own event log, and configure failure alerts. The status page describes what its probes actually measure. The terms define the uptime commitment and any applicable credits.
Start free
Watch your app. Keep every event.
Verify a domain for a free leak scan and three tripwires, or point a provider at an endpoint. Both run on one account and one event allowance.