skip to content

What are group.min.session.timeout.ms and group.max.session.timeout.ms, and what happens if a consumer requests a session timeout outside them?

level: seniorimportance: should knowfreq 45%

answer

  1. broker floor 6000ms, ceiling 1800000ms
  2. server.properties, cluster-wide
  3. out of range -> INVALID_SESSION_TIMEOUT
  4. rejected, not clamped
  5. prevents rebalance storms / stuck partitions

basics

~20 s

They are broker-side limits on the session.timeout.ms a consumer may request: group.min.session.timeout.ms (default 6000 ms) and group.max.session.timeout.ms (default 1800000 ms). A consumer asking for a value outside this range is rejected and cannot join the group.

solid answer

~40 s

session.timeout.ms is configured on the consumer, but the broker enforces an allowed range so operators can prevent abusive values that destabilize groups. group.min.session.timeout.ms (default 6000 ms) stops consumers from requesting a window so short that normal jitter would cause constant evictions and rebalance storms. group.max.session.timeout.ms (default 1800000 ms = 30 minutes) stops consumers from requesting a window so long that a genuinely dead consumer holds its partitions for an unacceptable time before detection. When a consumer's JoinGroup request carries a session.timeout.ms outside [min, max], the coordinator rejects it with an InvalidSessionTimeout error, and the consumer fails to join until it picks a compliant value. These are broker (server.properties) configs and apply cluster-wide to all groups.

go deeper

for a junior

Know the broker sets allowed min/max session timeouts and out-of-range requests are refused.

for a middle

Recall the defaults (6000 / 1800000 ms) and that they live in server.properties.

for a senior

Explain the rejection (INVALID_SESSION_TIMEOUT, not clamp) and why operators bound the value (rebalance storms vs stuck partitions).

for a principal

Set cluster policy on these bounds and recognize ceiling-pushers as a max.poll.interval.ms misuse signal.

## Why brokers bound the value `session.timeout.ms` lives on the consumer, but if every team could set it freely they could harm the cluster: a tiny timeout causes endless rebalances (a 'rebalance storm') that stall the whole group; an enormous timeout means a crashed consumer's partitions go unprocessed for a very long time, inflating lag. To keep groups well-behaved, the **broker** defines an acceptable range and rejects out-of-range requests. ## The two broker configs (server.properties) - **`group.min.session.timeout.ms`** — default **6000 ms**. The floor. Consumers cannot request a session timeout below this. - **`group.max.session.timeout.ms`** — default **1800000 ms (30 minutes)**. The ceiling. Consumers cannot request a session timeout above this. Both are cluster-wide broker settings; they are not per-group unless using overrides, and they apply to all consumer groups managed by that broker. ## What happens on violation When a consumer sends a `JoinGroup` request, the coordinator validates the requested `session.timeout.ms`. If it is `< group.min.session.timeout.ms` or `> group.max.session.timeout.ms`, the coordinator responds with the error code **`INVALID_SESSION_TIMEOUT`**, the join fails, and the consumer cannot become a group member until it requests an in-range value. This surfaces in the client as an exception/log rather than a silent clamp — Kafka does **not** quietly round the value into range. ## Operational guidance - Lower `group.min.session.timeout.ms` cautiously if a latency-sensitive workload needs faster failure detection, and only if the environment has stable networking and short GC pauses. - The 30-minute ceiling is generous; rarely should a real consumer need anywhere near it. If teams are pushing the ceiling, that usually signals they're misusing session.timeout.ms to mask slow processing — which should be solved with `max.poll.interval.ms` instead. ## Edge cases / nuances - These bounds constrain `session.timeout.ms`, not `heartbeat.interval.ms` or `max.poll.interval.ms`. - Because the broker rejects rather than clamps, a misconfigured consumer will appear to 'never join' — a classic head-scratcher to debug if you don't check the broker bounds. - The new consumer-group protocol (KIP-848) moves more of this coordination server-side, but the notion of broker-enforced session bounds remains.

  • Does the broker clamp an out-of-range value or reject it?
    It rejects it with INVALID_SESSION_TIMEOUT; the consumer fails to join. Kafka does not silently round the value into the allowed range.
  • A team keeps raising session.timeout.ms toward the 30-minute ceiling — what does that usually indicate?
    They're likely masking slow per-batch processing. The correct fix is raising max.poll.interval.ms, not the session timeout, which is for crash/network detection.

saying these in an interview costs you the question

  • Claiming the broker silently clamps the value into range instead of rejecting the join.
  • Saying these bounds limit heartbeat.interval.ms or max.poll.interval.ms.
  • Thinking they are consumer-side configs.

context

resolving links…