A delivery layer built for production.
At-least-once delivery, retries with backoff, replay, and a per-attempt audit trail, the reliability primitives your customers expect from infrastructure they trust their data to.
Reliability primitives
Six things every production delivery layer needs. Pushrail ships them as the baseline, not the upsell.
At-least-once delivery
Every accepted event reaches every routed destination at least once. Persistent queue, durable acknowledgments, no silent drops.
Retries with backoff
Exponential backoff with jitter, capped at 24 hours. Transient failures (5xx, throttling, timeouts) retry. Permanent failures (4xx, auth) don't.
Replay
Re-run a single failure, a time window, or the whole DLQ. Same payload, same routing, same destination, idempotent on the customer's side.
Dead-letter queue
Anything that exhausts retries sits in a per-destination DLQ until inspected, fixed, and replayed, or expired per the retention window.
Per-attempt audit trail
Every delivery attempt logged with timestamp, status code, latency, error detail, and transformed payload (sealed under Private Payload Mode). Searchable by event, customer, or destination.
Failure classification
Transient vs permanent, classified at the adapter level. Permanent failures fail fast to the DLQ; transient retry with backoff. No infinite-retry traps.
Retries that classify
Not every failure is the same. Transient failures retry; permanent failures fail fast. The distinction matters.
A 503 from a customer's webhook server is transient: retrying tomorrow probably works. A 401 is permanent: retrying with the same expired credential won't help. A 200 with an error body is the customer's bug, not ours; we count it as success.
Pushrail classifies every failure at the adapter level. Transient failures (5xx, timeouts, throttling, network errors) retry with exponential backoff and jitter for up to 24 hours. Permanent failures (4xx other than 408/429, auth errors, missing-resource errors) land in the DLQ immediately so the customer sees the problem and can fix it.
The classification rules are visible per destination type. There's no infinite-retry trap, no silently-dropped events, no situation where 'it'll eventually retry' becomes a substitute for 'we need to look at this.'
Replay anything
Pick a destination, a time window, or a single failed delivery. Pushrail re-runs with the same payload your customer would have seen.
Observability is the product, not the README
Per-delivery logs, per-destination health, per-tenant audit trail. The questions your customer asks have answers in seconds.
Every delivery answers the same questions every time: did event X get sent? To which destinations? What was the response? How long did it take? If it failed, why? Pushrail surfaces these as queryable per-attempt records, not as application log lines you have to dig through after the fact.
Per-destination health rolls up the attempt records into a single status: healthy, degraded, failing. When a customer's webhook server starts 5xx-ing, the destination shows as degraded before the next on-call ticket lands.
Audit trail entries record every config change, every credential rotation, every replay trigger. Exportable on demand for compliance reviews.
How event-delivery fits the rest of Pushrail
Reliability primitives apply uniformly across every destination type and every tenant.
Browse all 18 destinations to see how each adapter applies these primitives. The retry, replay, and audit primitives are identical across webhooks, warehouses, queues, storage, databases, and analytics, your customers get one mental model, not 18.
Browse destinations →