kafka consumer rebalance loop, offsets not committing

TL;DR

A consumer group rebalances whenever a member joins, leaves, or is expelled for missing its poll deadline. In a loop, the group never finishes reassignment long enough to process and commit, so offsets stay put and lag climbs even though the consumers look busy. The usual driver is processing between polls taking longer than the max poll interval, a slow record or a big batch, or a member crashing on the same record every time. Shorten the work per poll, raise the interval to match reality, and fix the record that kills the member.

kafka consumer rebalance loop, offsets not committing

Use this when

• Consumer group logs show joining group and revoking partitions over and over for the same members.
• Lag grows steadily while consumers use CPU and appear to be working.
• Offsets for the group barely move even though records are being read.

Not for this skill when

• One rebalance follows a deploy, a restart, or a partition count change. That is normal group behaviour.
• The consumer is a Kafka Connect sink task in a failed state. That is a task failure with its own trace, not a group loop.

Steps

1. Read the consumer logs for one member across a few minutes and note the cycle: partitions revoked, a rejoin, reassignment, then another revocation, plus any poll timeout or heartbeat warnings. Note the time between revocation and rejoin. Verify: the loop is shown in one member's own log, with its period
2. Measure the processing time per poll batch and compare it with the configured max poll interval and the maximum records per poll. Note which batches overrun, and whether one partition or one record type is always in them. Verify: the overrun is measured against the actual config values
3. If one record or one kind of payload precedes every expulsion or crash, isolate it: log its partition and offset, fix the handling or route it aside under your error policy, and note the member survives passing that offset. Verify: a poison record cause is confirmed or cleared
4. Tune the group for the real workload: reduce the records per poll so a batch finishes well inside the interval, raise the max poll interval only if processing is legitimately long, and check the session and heartbeat timeouts are in a sane ratio. Note the new values. Verify: a normal batch can finish and commit inside one assignment
5. Consider static group membership for members with stable identities so a brief restart rejoins without a full rebalance, then watch the group state settle and the committed offsets advance steadily for a full cycle. Note lag falling per partition. Verify: the group stays stable and offsets commit continuously

Variant phrasings

kafka consumer keeps rebalancing max.poll.interval.ms exceeded

The config shaped phrasing naming the poll interval setting that this failure usually turns on.

kafka consumer group rebalancing constantly lag increasing no commits

The symptom only version.

Compatibility: Apache Kafka Java and librdkafka based consumers, and Connect workers which run consumer groups internally. Config names given are the Java client spellings; other clients expose the same settings under similar names.

Why it happens

Rebalancing is the group's safety mechanism, designed for members that genuinely come and go. It becomes the failure when a healthy but slow member looks dead to the coordinator: the member is busy processing a batch, misses its poll deadline, gets expelled, and its partitions are revoked mid work, so the processing is discarded and nothing commits. On rejoin it is assigned the same partitions and starts on the same batch, which overruns again. Every component is doing its documented job, and the composition is a machine for never making progress.

Edge cases / pitfalls

• Raising the poll interval without shrinking batches can hide the loop while making real member failures slower to detect. Tune both together.
• A rebalance storm can be caused by too many members for the partitions, leaving some idle and restless. Match member count to partition count.
• Committing offsets manually inside a long processing step, before the work is durably done, trades the loop for data loss on a crash. Commit after the write the offset represents.
• During the loop, other groups on the same cluster are unaffected. If every group is rebalancing, look at broker or network health instead of consumer config.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GaBamcEzqUFboR2oa6ZVtw