🚨 Kafka Error Guide: 'NotCoordinatorException: This is not the correct coordinator' — Refresh the Group Coordinator

Overview

NotCoordinatorException is returned when a client sends a group request (offset commit, join, heartbeat) to a broker that is not the coordinator for that consumer group. The client sees it in logs during commits or rebalances:

org.apache.kafka.common.errors.NotCoordinatorException: This is not the correct coordinator.
[2026-07-09 11:02:44] WARN [Consumer clientId=orders-1, groupId=orders] Offset commit failed on partition orders-3: This is not the correct coordinator.

It is normally transient and retriable: the client is expected to re-discover the coordinator and retry. It becomes a problem only when it persists, which points to __consumer_offsets trouble rather than a simple coordinator move.

Symptoms

• Consumers log repeated NotCoordinatorException warnings around commits, joins, or heartbeats.
• Offset commits fail and lag appears to freeze while the client re-discovers the coordinator.
• Rebalances take longer than usual or loop while coordinator lookup keeps failing.
• Errors cluster right after a broker restart, leadership change, or partition reassignment of __consumer_offsets.
• Persistent (non-transient) errors coincide with an offline or under-replicated __consumer_offsets partition.

Common Root Causes

• Coordinator moved — the broker hosting the group’s __consumer_offsets partition changed leadership (restart, rolling upgrade, reassignment) and the client still holds the old coordinator.
• Stale client metadata — the consumer cached an old coordinator and has not refreshed after a leadership change.
• __consumer_offsets partition offline or under-replicated — the partition that owns the group has no available leader, so no broker will accept coordinator duties.
• Broker just started — the coordinator partition is still loading, so the broker disowns the group briefly (often alongside CoordinatorLoadInProgressException).
• Wrong offsets-topic replication factor — offsets.topic.replication.factor=1 means a single broker outage removes the coordinator entirely.

Diagnostic Workflow

Find the current coordinator for the affected group:

kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --describe --group orders --state

Inspect the __consumer_offsets topic for offline or under-replicated partitions:

kafka-topics.sh --bootstrap-server localhost:9092 \
  --describe --topic __consumer_offsets | grep -E 'Leader: -1|Isr'

Confirm the replication factor of the offsets topic is not 1:

kafka-topics.sh --bootstrap-server localhost:9092 \
  --describe --topic __consumer_offsets | head -1

Check for recent leadership changes or coordinator load messages on the brokers:

grep -iE 'coordinator|GroupCoordinator|Loading group metadata' \
  /var/log/kafka/server.log | tail -30

Verify overall cluster health so you can tell a transient move from a real outage:

kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-replicated-partitions

Example Root Cause Analysis

During a rolling restart, several consumer groups began logging NotCoordinatorException on every commit and never recovered. Normally this clears in seconds, so the persistence was the tell.

kafka-topics.sh --describe --topic __consumer_offsets showed three partitions with Leader: -1 — offline. The cluster had been created long ago with offsets.topic.replication.factor=1, so those __consumer_offsets partitions lived on the single broker that was down for the restart. With no replicas, no broker could become coordinator for the groups mapped to those partitions.

Bringing the restarting broker back online restored the offline partitions and the errors cleared instantly. The permanent fix was to raise the offsets-topic replication factor to 3 via a partition reassignment so a single broker restart can never orphan a coordinator again. Consumers, which had been retrying correctly the whole time, resumed committing without intervention.

Prevention Best Practices

• Set offsets.topic.replication.factor=3 (and min.insync.replicas=2) so no single broker outage removes a group coordinator.
• Roll brokers one at a time and wait for ISR to fully recover between restarts so coordinators always have a live replica.
• Alert on __consumer_offsets partitions with Leader: -1 — an offline coordinator partition is the usual cause of persistent errors.
• Keep client libraries current; modern consumers re-discover the coordinator and retry transient NotCoordinatorException automatically.
• Treat brief bursts of this error during leadership changes as normal, and alert only when it persists beyond the client’s retry window.

Quick Command Reference

# Current coordinator and group state
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group orders --state

# Offline / under-replicated offsets partitions
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic __consumer_offsets | grep 'Leader: -1'

# Offsets topic replication factor
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic __consumer_offsets | head -1

# Coordinator activity in broker logs
grep -iE 'GroupCoordinator|Loading group metadata' /var/log/kafka/server.log | tail

# Cluster-wide replication health
kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-replicated-partitions

Conclusion

NotCoordinatorException means a client asked the wrong broker to manage its consumer group. As a transient event during coordinator moves it is harmless and self-healing — clients re-discover and retry. When it persists, the real problem is the __consumer_offsets topic: an offline or under-replicated coordinator partition, almost always because the offsets topic was created with replication factor 1. Verify offsets-topic health, restore the missing replica, and raise the replication factor to 3 so coordinators survive broker restarts.