ShellOrbit / Reliability

Recovery starts before the first retry.

Understand how ShellOrbit accepts events, schedules delivery, handles failures, and retains the evidence you need.

PATCH /v1/endpoints/ep_example
{
  "retry_policy": {
    "max_attempts": 12,
    "strategy": "exponential",
    "initial_delay_seconds": 30,
    "max_delay_seconds": 3600
  }
}

Set per endpoint on paid plans: up to 50 attempts, exponential, linear, or fixed backoff, at most a day apart. Hobby uses a fixed policy of 5 attempts.

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 with one provider

Give your next webhook a clear destination.

Create an endpoint, connect your handler, and send a test event.

Start free Read the quickstart