max.poll.interval.ms — Kafka Consumer Configuration
The maximum delay between invocations of poll() when using consumer group management. This places an upper bound on the amount of time that the consumer can be idle before fetching more records.
Description
The maximum delay between invocations of poll() when using consumer group management. This places an upper bound on the amount of time that the consumer can be idle before fetching more records. If poll() is not called before expiration of this timeout, then the consumer is considered failed and the group will rebalance in order to reassign the partitions to another member. For consumers using a non-null group.instance.id which reach this timeout, partitions will not be immediately reassigned. Instead, the consumer will stop sending heartbeats and partitions will be reassigned after expiration of session.timeout.ms. This mirrors the behavior of a static consumer which has shutdown.
Default Values by Kafka Version
| Kafka Version | Default Value |
|---|---|
| 0.10.1 | 300000 |
| 0.10.2 | 300000 |
| 0.11.0 | 300000 |
| 1.0 | 300000 |
| 1.1 | 300000 |
| 2.0 | 300000 |
| 2.1 | 300000 |
| 2.2 | 300000 |
| 2.3 | 300000 |
| 2.4 | 300000 |
| 2.5 | 300000 |
| 2.6 | 300000 (5 minutes) |
| 2.7 | 300000 (5 minutes) |
| 2.8 | 300000 (5 minutes) |
| 3.0 | 300000 (5 minutes) |
| 3.1 | 300000 (5 minutes) |
| 3.2 | 300000 (5 minutes) |
| 3.3 | 300000 (5 minutes) |
| 3.4 | 300000 (5 minutes) |
| 3.5 | 300000 (5 minutes) |
| 3.6 | 300000 (5 minutes) |
| 3.7 | 300000 (5 minutes) |
| 3.8 | 300000 (5 minutes) |
| 3.9 | 300000 (5 minutes) |
| 4.0 | 300000 (5 minutes) |
| 4.1 | 300000 (5 minutes) |
| 4.2 | 300000 (5 minutes) |
Tuning Recommendation
| Profile | Recommended | Why |
|---|---|---|
| consumer / throughput | 600000 | When processing large batches (max.poll.records=2000) with expensive operations (DB writes, external API calls), 5 minutes may be insufficient. Raising to 10 minutes prevents spurious rebalances triggered by slow batch processing, which reset progress and create rebalance storms under high load. |
| consumer / latency | 30000 | For latency-sensitive consumers processing small batches (100 records), 30 seconds is a generous bound. Reducing it from 5 minutes forces faster detection of stalled consumers: a genuinely hung consumer is evicted within 30s instead of 5 minutes, allowing its partitions to be reassigned quickly. |
| consumer / durability | 300000 | For durable processing with external side effects (DB writes, downstream API calls), 5 minutes provides a conservative safety margin. Reducing it risks false evictions during legitimate slow operations (e.g., a large DB transaction); being evicted mid-processing without committing is the worst case for durability — it causes silent reprocessing of partial results. |
Related Configs
max.poll.records · session.timeout.ms · heartbeat.interval.ms · partition.assignment.strategy · group.instance.id