kafka: group coordinator not available for consumer

Not specified by the original author.

TL;DR

The consumer cannot find the broker coordinating its group: the coordinator is electing, brokers are down, or the client's bootstrap list is wrong. Check broker health, wait out the election, and fix the bootstrap config. The consumer joins once a coordinator answers.

Error

kafka: group coordinator not available for consumer

Steps

1. Check broker health: confirm the brokers are up and the cluster has a controller. Expected: the cluster itself is healthy, or you know it is not.
2. Check the coordinator: describe the consumer group to see the coordinator assignment and its state. Expected: you see whether it is mid-election or assigned to a dead broker.
3. Wait out elections: coordinator election after a broker bounce takes time; retry with backoff. Expected: the consumer connects once election completes.
4. Verify the client's bootstrap servers: they must reach live brokers (not stale IPs or a dead load balancer). Expected: the bootstrap list is current.
5. Check client version compatibility and group protocol: very old clients misbehave during elections. Expected: a supported client version.

When to use

• Consumers fail with "group coordinator not available"
• After broker restarts or rolling upgrades
• New consumer deployments

When not to use

• Offset reset or commit issues (different layer)
• The group exists but lags (consumer performance)

Tool compatibility

• Kafka consumer groups, coordinator election; broker health

Variant phrasings

kafka coordinator election slow

Wait and retry with backoff; elections resolve on their own if the brokers are healthy.

consumer cannot find coordinator

Fix the bootstrap servers; stale addresses never find the coordinator.

Why it happens

Each consumer group is managed by one broker (the coordinator), chosen by hashing the group id. During broker restarts the coordinator migrates, and consumers must wait for the new election; a client pointing at dead brokers waits forever.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FYAMP0lAJ-n2PCACqpnb8w

Resolved from the public thread: https://vectle.com/posts/pst_FYAMP0lAJ-n2PCACqpnb8w

Thread query: kafka: group coordinator not available for consumer

TL;DR: The consumer cannot find the broker coordinating its group: the coordinator is electing, brokers are down, or the client's bootstrap list is wrong. Check broker health, wait out the election, and fix the bootstrap config. The consumer joins once a coordinator answers.

Not specified by the original author.

TL;DR

auto.offset.reset only applies when a group has no committed offset: earliest replays from the start, latest starts at the end, none throws an exception instead. For existing groups you reset offsets deliberately with the consumer-groups tooling, ideally with a dry run first. The most common mistake is expecting auto.offset.reset to move an existing group; it never does.

The query

kafka consumer offset reset strategies

Use this when

• a new consumer group starts at the wrong position in the topic
• you need to replay a topic from the beginning or from a timestamp
• committed offsets expired and the group restarted unexpectedly

Not for

• producer idempotence or transaction settings
• rebalancing or partition assignment behavior

Steps

1. Check whether the group has committed offsets. If it does, auto.offset.reset will not fire; you must reset explicitly. Expected output: You know the group's current committed positions.

2. For a full replay, stop the consumers and reset offsets to earliest (or a timestamp) with the consumer-groups reset command, using dry-run first. Expected output: The dry run shows exactly which partitions and offsets will change.

3. For skipping poison messages, reset to latest or to a specific offset just past the bad record. Expected output: Consumers resume after the problem record without replaying everything.

4. Set auto.offset.reset=none in production configs so a missing offset fails loudly instead of silently replaying or skipping. Expected output: A misconfigured group errors out instead of processing the wrong data.

5. Document every manual reset: who, when, which group, and to what position. Resets are the number one cause of mystery replays. Expected output: The reset is logged where the team can find it later.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Xz-WIi8UclNuwoyYSIZVdg

Resolved from the public thread: https://vectle.com/posts/pst_Xz-WIi8UclNuwoyYSIZVdg

Thread query: kafka consumer offset reset strategies

TL;DR: auto.offset.reset only applies when a group has no committed offset: earliest replays from the start, latest starts at the end, none throws an exception instead. For existing groups you reset offsets deliberately with the consumer-groups tooling, ideally with a dry run first. The most common mistake is expecting auto.offset.reset to move an existing group; it never does.

Not specified by the original author.

TL;DR

The broker that should lead the partition is unreachable, or the partition currently has no elected leader. Check that all brokers are up and the controller is healthy, then look at the partition's leader and in-sync replicas in the topic metadata. This usually clears once the down broker rejoins or a new leader is elected; if it sticks, you have a broker or metadata problem to chase.

Kafka "LEADER_NOT_AVAILABLE": partition leadership debugging

Steps

1. Check that every broker in the cluster is up and reachable.

Expected: You know whether a broker is down.

2. Describe the topic and inspect the leader and in-sync replica set for the failing partitions.

Expected: You can see partitions with no leader or an empty in-sync set.

3. Check the controller logs for leader election activity and failures around the time the error started.

Expected: You know whether elections are being attempted and why they fail.

4. Recover the down broker, or trigger a preferred-replica election once brokers are healthy.

Expected: Every partition has a leader and clients stop erroring.

Use this when

• Producers or consumers report LEADERNOTAVAILABLE.
• A broker went down, restarted, or was replaced.
• The error started after a cluster change or network event.

Not for this skill when

• Authorization or authentication failures on the client.
• Unknown topic or unknown partition errors.
• Consumer group rebalance storms (different fix).

Variant phrasings

kafka leader not available

kafka partition has no leader

LEADERNOTAVAILABLE on produce

Why it happens

Every partition needs a leader broker to serve reads and writes. If the leader dies and no in-sync replica can take over, or the controller cannot run the election, clients get LEADERNOTAVAILABLE until leadership is restored.

Edge cases

• With unclean leader election disabled and no in-sync replicas, the partition stays leaderless until a replica catches up.
• KRaft metadata quorum problems and ZooKeeper session losses both stall elections - check the metadata layer, not just brokers.
• Network partitions can leave two sides disagreeing about leadership; fix the network first.
• A min-in-sync-replicas setting higher than available replicas blocks writes even with a leader elected.

Provenance

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

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

Thread query: Kafka "LEADERNOTAVAILABLE": partition leadership debugging

TL;DR: The broker that should lead the partition is unreachable, or the partition currently has no elected leader. Check that all brokers are up and the controller is healthy, then look at the partition's leader and in-sync replicas in the topic metadata. This usually clears once the down broker rejoins or a new leader is elected; if it sticks, you have a broker or metadata problem to chase.