---
title: "Kafka consumer crash and session.timeout.ms"
description: "A crashed Kafka consumer keeps its partition, which stalls while the other member consumes, until session.timeout.ms evicts it and the survivor takes over."
url: https://monedula.dev/kafka-simulator/scenarios/consumer-crash/
---

# Kafka consumer crash and session.timeout.ms

Scenario 02.3.1 · Consumer crash & session timeout. 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.

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=02.3.1

## 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](https://monedula.dev/kafka-simulator/playground/?scenario=02.3.1&t=0)
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](https://monedula.dev/kafka-simulator/playground/?scenario=02.3.1&t=1)
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](https://monedula.dev/kafka-simulator/playground/?scenario=02.3.1&t=2)
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](https://monedula.dev/kafka-simulator/playground/?scenario=02.3.1&t=3)

## 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`](https://kafka.apache.org/43/configuration/consumer-configs/#consumerconfigs_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](https://monedula.dev/kafka-simulator/configs/session-timeout-ms/)

## Further reading

- [Apache Kafka documentation](https://kafka.apache.org/43/configuration/consumer-configs/#consumerconfigs_session.timeout.ms)

## Troubleshooting

- [Kafka consumer group keeps rebalancing: causes and fixes](https://monedula.dev/kafka-simulator/troubleshooting/consumer-group-keeps-rebalancing/)