Delivery, Retries and Failures
What counts as success
Your server must reply with a 2xx status within 8 seconds. The following count as failures: non-2xx statuses, 3xx redirects (not followed), timeouts, and connection errors. Etalasse reads only the first 2 KB of the response and keeps 1000 characters for the log.
Retry schedule
| Attempt | When |
|---|---|
| 1 | Immediately |
| 2 | 1 minute later |
| 3 | 5 minutes |
| 4 | 30 minutes |
| 5 | 2 hours |
| 6 | 6 hours |
| 7 | 24 hours |
Plus 0-10 percent random jitter. That is 7 attempts over about 33 hours. If all fail, the delivery becomes dead (dead letter) and can be redelivered from the log.
Delivery statuses
| Status | Meaning |
|---|---|
pending | Waiting for its time |
sending | Being sent |
succeeded | Delivered |
dead | All attempts failed |
skipped | Skipped because the endpoint was disabled, deleted, or no longer covered by the plan when it came due |
Error codes in the log
The last-error column holds one of: HTTP_<status> (a non-2xx reply, 3xx included), TIMEOUT, CONNECT_FAILED, CONNECTION_RESET, TLS_ERROR (invalid certificate or one for another name), NO_RESPONSE, BAD_RESPONSE, BAD_REQUEST, and SECRET_UNREADABLE (the server key changed: rotate the endpoint secret). A URL refused at delivery time appears as URL_SCHEME, URL_HOST_BLOCKED, URL_PORT_BLOCKED, ADDRESS_BLOCKED or DNS_FAILED. A skipped delivery carries the reason ENDPOINT_INACTIVE, ENDPOINT_DELETED, PLAN_LIMIT or EVENT_MISSING.
Automatic disabling
An endpoint with 10 or more failed attempts and no success for 3 days is disabled automatically (reason: auto_failures). The shop owner gets an in-app notification.
To turn it back on:
- Fix the cause of the failures on your server.
- Re-enable the endpoint (active switch or Enable button). The failure counter is reset.
- Replay the events you missed.
Events that happen while an endpoint is disabled are not sent automatically after you re-enable it. Use replay to catch up, as long as they are still within the 30-day retention.
Delivery log
The log shows every delivery, newest first. Available filters: endpoint, status, event type, kind (event, test, redelivery), and date range. Each row shows the status, HTTP code, latency, attempt count (n/7), and the next attempt time. Row detail includes the history of each attempt, the JSON that was sent, and a response excerpt.
Logs and events are kept for 30 days.
Redeliver
The Redeliver button on a row creates a new delivery (kind redelivery) of the same event to the same endpoint and sends it right away. The old row is untouched so history stays intact. It works for any status, provided the endpoint is active.
Replaying events
From the recent events list (or the order page, where your Dashboard offers it) you can replay an event:
- to one specific endpoint, or
- to every active endpoint subscribed to it (subscription as it is now).
Replay works only for events from the last 30 days and for active endpoints.
Guarantees
- At-least-once, unordered. Build duplicate handling on the event
id. - An event is recorded in the same database transaction as its change: no event for a rolled-back change, and none lost if the server crashes after commit.
- Usually arrives within a few seconds. A background worker runs every minute as a safety net.
- Concurrent workers never send the same delivery at the same time.
- Bodies are under 256 KB.
Tips for a healthy endpoint
- Reply 2xx fast; do heavy work in your own queue.
- Also reply 2xx for duplicate events you have already processed.
- Do not reply with 3xx; the endpoint must answer directly.
- Check notifications and the log regularly.