> For the complete documentation index, see [llms.txt](https://docs.chord.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chord.co/activate/event-streaming/errors-and-retries.md). # Errors and retries Chord processes each event, then sends it to your destinations. Either step can fail. This page explains which failures Chord retries, how it schedules retries and what you see when a mapping is wrong. ## How delivery works Chord delivers each event at least once. When a failure is temporary, Chord holds the event and tries again later. That means an event can occasionally arrive twice. See [Deduplication](/activate/event-streaming/deduplication.md). Chord delivers each event separately for each connection, which is one source paired with one destination. A failure on one destination doesn't affect the others. ## Failures Chord retries, and failures it doesn't A **temporary** failure should fix itself without any change from you. Examples are a destination returning a server error (`5xx`), a timeout, a rate limit or a network blip. Chord retries these. A **permanent** failure can't be fixed by trying again. Examples are bad event data that the destination will never accept, a login failure or a bug in a function. Chord doesn't retry these. Depending on the failure, it drops the event, records it as failed, or, for a function that throws a plain error, still sends it. Chord also sends a [notification](/activate/event-streaming/notifications.md) if you set one up. | What happened | Retried | Result | | -------------------------------------------------------------------------------- | ------- | -------------------------------------------------------------------------- | | Temporary failure at the destination (`5xx`, timeout, rate limit, network error) | Yes | Chord tries again with a delay and delivers once the destination recovers. | | A function throws `RetryError` | Yes | Chord tries again with a delay. | | The destination rejects the event for good (`4xx`, login or validation failure) | No | The event isn't delivered to that destination. You get a notification. | | A function throws `NoRetryError` | No | Chord drops the event. You get a notification. | | A function throws a plain `Error` | No | Chord still sends the event. You get a notification. | | A function returns `null`, `false` or `[]` | No | Chord quietly drops the event. No notification. | Functions can raise these errors on purpose. See [Functions](/activate/event-streaming/functions.md#errors). ## How retries are scheduled Chord doesn't retry right away. It sets a retry time and holds the event until then. Each wait is longer than the last, so a struggling destination gets time to recover. By default, Chord tries up to 3 more times, after about 10 minutes, then about 1.7 hours, then about 16.7 hours. No wait is longer than 24 hours. A retry starts at the step that failed. If delivery failed, Chord only tries delivery again. If a function failed, Chord runs the functions again and then delivers. ## Events that run out of retries If an event still can't be delivered after its last retry, Chord moves it to a holding area instead of retrying forever or deleting it. This keeps new events flowing and keeps the failed one available for review. You see the failure in your notifications if you set them up. Contact to ask about a failed event. ## Property mapping problems A wrong [property mapping](/activate/event-streaming/property-mappings.md) doesn't stop the event. Mappings belong to one connection, so a bad mapping only affects that destination. The most common problem is a source path that isn't on the event. Chord skips that mapping, logs a warning and sends the event with every other mapping applied. The destination just doesn't get that one field. Where you see the warning depends on the destination: * **Browser destinations** log it in the visitor's browser console. It names the destination and the mapping, and ends with `source path "" does not exist on event — mapping skipped`. It doesn't appear in Live Events. * **Server destinations** log it in [Live Events](/activate/event-streaming/live-events.md). If the warning shows on every event, limit the mapping's **Scope** to the events that carry the property. Mappings with a static value never warn. If a mapping fails in some other way, Chord logs an error and doesn't send that event to that destination. Other destinations still get it. If you see this, contact Chord support. It points to a problem on our side. ## Find failures Open **Live Events** to see each failure and its error. Choose **Errors** under **Status** to hide everything else. To get an email when failures start, set up [Notifications](/activate/event-streaming/notifications.md). Events that a function drops on purpose are recorded as dropped. They don't count as failures and don't send a notification. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.chord.co/activate/event-streaming/errors-and-retries.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.