Reference

Reliability & Limits

The concrete numbers behind delivery — timeouts, retries, rate limits, and payload size. Most of these are per-Endpoint defaults you can override, not hard walls.

Delivery timeout

SettingValueNotes
Per-request timeout5s default, 1–10s rangeConfigurable per Endpoint. This is how long your server has to respond before the attempt counts as a failure.
Worker HTTP client cap30sAbsolute outer ceiling — not configurable, exists as a safety net regardless of the per-endpoint setting.

Retry schedule

Fixed exponential backoff — the delay between attempts isn't configurable, but the total number of attempts is.

1st retry: 30s 5m 30m 2h 8h 24h (repeats)
SettingValueNotes
Max attempts10 defaultConfigurable per Endpoint (and per-Application default). After the last attempt fails, the message moves to the Dead Letter Queue.

Circuit breaker

SettingValueNotes
Trip threshold10 consecutive failuresNot configurable. Once tripped, the Endpoint's status becomes circuit_broken and deliveries to it pause — protecting your worker pool from spending all its time on an Endpoint that's clearly down.
ResetAutomatic on next successA single successful delivery resets the failure count to zero and restores active status.
The circuit breaker is per-Endpoint. One subscriber's outage never pauses deliveries to any other Endpoint, even within the same Application.

Rate limits

SettingValueNotes
Publish (per Application)1,000 events/min defaultEnforced at the ingestion API. Exceeding it returns 429 with a Retry-After header.
Delivery (per Endpoint)100 requests/min defaultConfigurable per Endpoint. Excess requests are requeued at the exact next available slot — not dropped, and not counted as a failed attempt.

Payload & idempotency

SettingValueNotes
Max payload size256 KiBLarger payloads are rejected at publish with 413, before anything is written.
Idempotency window24 hoursRe-publishing with the same Idempotency-Key header within this window returns the original event_id with duplicate: true instead of creating a second event.
Idempotency is scoped per Application, per key — the same key reused in a different Application is a different dedupe bucket, not a collision.