Scenario 02.3.1 · Consumer crash & session timeout

Kafka consumer crash and session.timeout.ms

Consumer groups · Intermediate · about 3 min · Apache Kafka 4.3

A crashed member keeps owning its partitions until session.timeout.ms - they stall while survivors consume - then it is evicted and a survivor takes over.

What you start with

A consumer proves it is alive with periodic heartbeats. This scenario crashes one member: the coordinator keeps its partitions assigned - they stall while survivors keep consuming - until session.timeout.ms elapses, then evicts it and rebalances those partitions to a survivor.

Step by step

1. Two-member group ready t+0.000s A 2-partition topic with a cooperative-sticky group of two consumers: c1 owns p0, c2 owns p1. Press play. Open at this step: step 1, Two-member group ready
2. Both consuming · lag 0 t+0.900s One record landed on each partition; c1 drained p0 and c2 drained p1. Both members are caught up. Open at this step: step 2, Both consuming · lag 0
3. c1 crashed · p0 stalls, c2 keeps consuming t+2.500s c1 crashed at t=1000 but still owns p0 until session.timeout.ms (2000 ms here; timings are compressed, real brokers require at least 6 s) elapses. New records on p0 are NOT consumed - its lag grows - while c2 keeps draining p1. This partial stall is what makes a crash different from a clean leave. Open at this step: step 3, c1 crashed · p0 stalls, c2 keeps consuming
4. Evicted · survivor took over t+4.000s At t=3000 the session timeout expired: c1 was evicted and p0 rebalanced onto the survivor c2, which now owns both partitions and has drained p0 back to lag 0. Open at this step: step 4, Evicted · survivor took over

The takeaway

session.timeout.ms sets how long a dead member's partitions stall before failure is detected; a shorter timeout recovers faster but risks evicting a consumer that only paused briefly.

Configs in this scenario

• session.timeout.ms How long the group coordinator waits for a heartbeat from a classic-protocol consumer before it removes the member and rebalances (default 45000, 45 seconds); with group.protocol=consumer the broker group.consumer.session.timeout.ms applies instead. How session.timeout.ms works

Embed this scenario

Paste this into a blog post, a course page or your team's docs. The scenario plays inside your page, and the link under it points readers to this walkthrough.

<iframe src="https://monedula.dev/kafka-simulator/embed/?scenario=02.3.1" title="Kafka Simulator: Consumer crash &amp; session timeout" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/consumer-crash/">Kafka consumer crash and session.timeout.ms</a></p>

Further reading

Apache Kafka documentation

Troubleshooting

• Kafka consumer group keeps rebalancing: causes and fixes

More in Consumer groups

• Kafka consumer poll loop: subscribe, poll, fetch
• Kafka auto.offset.reset: earliest vs latest vs none
• Kafka committed offsets: enable.auto.commit and restart
• Replay a Kafka topic: consumed records stay in the log
• Kafka consumer group: how partitions split across members
• Kafka consumer group rebalance when a consumer joins
• Kafka partition assignors: range vs round-robin vs sticky
• Kafka eager vs cooperative rebalancing (cooperative-sticky)
• Kafka max.poll.interval.ms: evicting a stuck consumer
• Kafka static membership: group.instance.id avoids rebalances
• Kafka consumer lag: why it grows and how it drains
• Evicted Kafka consumer: how a survivor takes its partition

All scenarios