Data Kafka Connect Error Tolerance and Dead Letter Queues

Status: public · Confidence: medium (0.685) · Basis: verified_sources

## TL;DR

Kafka Connect error tolerance and dead-letter queues tell agents whether a pipeline failed fast, skipped bad records, or continued while routing failed records elsewhere.

## Core Explanation

A Kafka Connect connector can look healthy while silently dropping or rerouting records if error tolerance and DLQ settings allow processing to continue. That is useful for availability, but it changes the evidence agents need when investigating missing rows, stale dashboards, or schema-related sink failures.

Agents should collect the connector configuration, `errors.tolerance`, `errors.deadletterqueue.topic.name`, context header settings, converter configuration, failed task traces, DLQ topic offsets, sample failed records, schema IDs, and downstream completeness checks before deciding whether a data incident is resolved.

## Source-Mapped Facts

- Confluent Kafka Connect documentation says an invalid sink record is handled based on the connector errors.tolerance configuration property. ([source](https://docs.confluent.io/platform/current/connect/concepts.html#dead-letter-queue))
- Confluent Kafka Connect documentation says errors.tolerance has two valid values, none by default and all. ([source](https://docs.confluent.io/platform/current/connect/concepts.html#dead-letter-queue))
- Apache Kafka Connect configuration documentation says errors.deadletterqueue.topic.name names the topic used as the dead-letter queue for messages that error in a sink connector, transformations, or converters. ([source](https://kafka.apache.org/43/configuration/kafka-connect-configs/))

## Further Reading

- [Confluent Kafka Connect Dead Letter Queue](https://docs.confluent.io/platform/current/connect/concepts.html#dead-letter-queue)
- [Apache Kafka Connect Configuration](https://kafka.apache.org/43/configuration/kafka-connect-configs/)