retry.backoff.ms — Kafka Consumer Configuration
The amount of time to wait before attempting to retry a failed request to a given topic partition. This avoids repeatedly sending requests in a tight loop under some failure scenarios.
Description
The amount of time to wait before attempting to retry a failed request to a given topic partition. This avoids repeatedly sending requests in a tight loop under some failure scenarios. This value is the initial backoff value and will increase exponentially for each failed request, up to the retry.backoff.max.ms value.
Default Values by Kafka Version
| Kafka Version | Default Value |
|---|---|
| 0.9.0 | 100 |
| 0.10.0 | 100 |
| 0.10.1 | 100 |
| 0.10.2 | 100 |
| 0.11.0 | 100 |
| 1.0 | 100 |
| 1.1 | 100 |
| 2.0 | 100 |
| 2.1 | 100 |
| 2.2 | 100 |
| 2.3 | 100 |
| 2.4 | 100 |
| 2.5 | 100 |
| 2.6 | 100 |
| 2.7 | 100 |
| 2.8 | 100 |
| 3.0 | 100 |
| 3.1 | 100 |
| 3.2 | 100 |
| 3.3 | 100 |
| 3.4 | 100 |
| 3.5 | 100 |
| 3.6 | 100 |
| 3.7 | 100 |
| 3.8 | 100 |
| 3.9 | 100 |
| 4.0 | 100 |
| 4.1 | 100 |
| 4.2 | 100 |
Tuning Recommendation
| Profile | Recommended | Why |
|---|---|---|
| producer / throughput | 100 | The 100ms initial backoff is appropriate; lowering it causes retry storms on leader elections that amplify broker load, while raising it wastes delivery.timeout.ms budget on unnecessary idle time. |
| producer / durability | 200 | Doubling the initial retry backoff to 200ms reduces the rate of retry storms during leader elections on high-partition-count topics, giving the controller time to elect a new leader before the producer hammers the cluster with retries. |
Related Configs
retries · delivery.timeout.ms · retry.backoff.max.ms
Manage Kafka configs across all your clusters with Conduktor Console — view, compare, and update configurations in one place.