Skip to content
Kafka Is Fun
ConsumerConsumer groups; the new protocol needs Kafka 4.0 or later
  • New consumer rebalance protocol (KIP-848): gA in 4.0

Consumer group keeps rebalancing

Checked against Kafka 4.2 · Oct 2026Community draft, not yet reviewed by a Kafka specialist

What it means

Whenever membership changes, the group rebalances. With an eager protocol a consumer must revoke all its partitions before taking part (the RebalanceProtocol Javadoc), and KIP-848 describes the classic protocol as relying on a group-wide synchronization barrier. A rebalance storm is when this happens again and again, so consumers spend their time rejoining instead of consuming.

Quick answer

Find out why members keep leaving: slow polling (max.poll.interval.ms), missed heartbeats, or restarts and scaling. Then make each rebalance cheaper with static membership, a cooperative assignor, or the new consumer protocol.

Likely causes, most common first

  1. Members leave because processing is too slow

    How to confirm

    The KafkaConsumer Javadoc says a consumer that does not call poll() at least as often as max.poll.interval.ms leaves the group. The state command shows the group's state and assignment strategy.

    confirm
    kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group payments --state

    Fix

    Apply the fixes from the CommitFailedException entry: a smaller max.poll.records, a larger max.poll.interval.ms, or processing on another thread with pause().

  2. Restarts or scaling keep changing the membership

    How to confirm

    Rebalances line up with deployments, restarts or scaling events.

    confirm
    # consumer configuration: static membership
group.instance.id=payments-consumer-1
session.timeout.ms=60000

    Fix

    KIP-345 describes static membership: a static member is removed only when its session times out, and a member that rejoins within the session timeout does not cause a full rebalance. The configuration documentation recommends combining group.instance.id with a larger session timeout to avoid rebalances caused by process restarts.

  3. An eager assignor stops every consumer on every change

    How to confirm

    RangeAssignor, RoundRobinAssignor and StickyAssignor use the eager protocol, which requires a consumer to revoke all its owned partitions before a rebalance. Only CooperativeStickyAssignor also supports cooperative rebalancing. The default partition.assignment.strategy is [RangeAssignor, CooperativeStickyAssignor], which uses RangeAssignor until you change it.

    confirm
    # consumer configuration (default: RangeAssignor,CooperativeStickyAssignor)
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

    Fix

    With the default list, a single rolling bounce that removes RangeAssignor moves the group to cooperative rebalancing, which the configuration documentation states. If you start from an eager-only list, KIP-429 says you need two rolling bounces: first keep both assignors, then remove the old one. Kafka 4.0 and later also offer the new consumer protocol (group.protocol=consumer), which does not rely on the group-wide barrier.

See it happen

Trigger a consumer rebalance

Opens the simulator with this exercise already running. About 5 minutes.

Reproduce in the simulator

Sources

Every claim above comes from these Apache pages, as of Kafka 4.2. If a page does not say it, this entry does not.

Was this helpful?

Report an issue (opens GitHub in a new tab)

Back to all errors