🚨 Kafka Error Guide: 'LeaderNotAvailableException' Leader Election in Progress

Exact Error Message

This exception appears in producer or consumer logs, usually right after a topic is created or during a leadership change:

[2026-06-29 09:14:33,201] WARN [Producer clientId=producer-1] Error while fetching metadata with correlation id 7 : {orders-v2=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
org.apache.kafka.common.errors.LeaderNotAvailableException: There is no leader for this topic-partition as we are in the middle of a leadership election.

It is frequently logged simply as Leader not available or surfaced through a CLI tool:

Error while executing topic command : org.apache.kafka.common.errors.LeaderNotAvailableException
[2026-06-29 09:14:33,540] ERROR LeaderNotAvailableException: Topic 'orders-v2' partition 0 has no current leader. (kafka.admin.TopicCommand$)

What the Error Means

LeaderNotAvailableException means the client asked to produce to or fetch from a partition, but that partition currently has no elected leader. Every Kafka partition has exactly one leader replica that handles all reads and writes; if there is no leader, the partition cannot serve requests until one is elected.

This is a retriable exception. In the overwhelmingly common case it is transient: a topic was just created and the controller has not yet propagated leader assignments, or a leader moved during a restart and election is in flight. Clients retry on their metadata refresh interval and recover within a second or two without any operator action.

It becomes a real incident only when it persists, which indicates partitions are genuinely leaderless — for example because the leader replicas are on offline brokers and no in-sync replica is available to take over.

Common Causes

• Brand-new topic. Right after creation, the controller is still assigning and propagating leadership; the first produce/fetch races ahead of metadata.
• Leader election in progress. A broker restart, rolling upgrade, or controller failover temporarily leaves partitions without a leader while a new one is elected.
• Stale client metadata. The client holds an old view that points at a broker that is no longer the leader.
• Offline partitions. All replicas (or all in-sync replicas) for a partition are on down brokers, so no leader can be elected.
• unclean.leader.election.enable=false with no in-sync replica available — the partition stays leaderless rather than electing a stale replica.
• Controller problems. A struggling or absent controller cannot drive elections.

How to Reproduce the Error

Create a topic and immediately produce to it before metadata settles:

# Create a topic, then immediately try to use it
kafka-topics.sh --bootstrap-server kafka-1:9092 --create --topic ephemeral-demo --partitions 6 --replication-factor 3
kafka-broker-api-versions.sh --bootstrap-server kafka-1:9092   # any immediate metadata-driven call

A producer started against ephemeral-demo in the same instant will often log LEADER_NOT_AVAILABLE for the first few attempts, then succeed once leadership propagates. To reproduce the persistent form, stop the brokers hosting all replicas of a partition and observe that the leader never returns.

Diagnostic Commands

Inspect partition leadership and which partitions are leaderless:

kafka-topics.sh --bootstrap-server kafka-1:9092 --describe --topic orders-v2
# Partitions showing "Leader: none" or "Leader: -1" are the problem
kafka-topics.sh --bootstrap-server kafka-1:9092 --describe --under-replicated-partitions
kafka-topics.sh --bootstrap-server kafka-1:9092 --describe --unavailable-partitions

Check the controller and cluster quorum health:

kafka-metadata-quorum.sh --bootstrap-server kafka-1:9092 describe --status
kafka-cluster.sh cluster-id --bootstrap-server kafka-1:9092

Confirm brokers are up and look at controller/election activity in the logs:

kafka-broker-api-versions.sh --bootstrap-server kafka-1:9092
sudo journalctl -u kafka --since "10 min ago" | grep -iE 'election|leader|controller'
grep -iE 'unclean.leader.election|min.insync.replicas' /opt/kafka/config/server.properties

Step-by-Step Resolution

1. Wait and let the client retry first. If the topic was just created or a broker just restarted, the exception is almost certainly transient — confirm the client recovers within a few seconds before doing anything else.
2. Describe the topic. kafka-topics.sh --describe --topic <name>. If every partition now shows a valid Leader, the issue was transient and is resolved.
3. Find leaderless partitions. Use --unavailable-partitions. Any listed partition has no leader and needs attention.
4. Check the brokers hosting those replicas. Run kafka-broker-api-versions.sh and systemctl status kafka on each. If replica brokers are down, bringing them back online lets a leader be elected.
5. Verify the controller is healthy. kafka-metadata-quorum.sh describe --status should show a current leader for the metadata quorum. A missing controller blocks all elections.
6. Review ISR vs replicas. If Isr is empty for a partition and unclean.leader.election.enable=false, no leader can be chosen until an in-sync replica returns. Restore a broker that held an in-sync replica.
7. Confirm recovery. Re-describe the topic; all partitions should show a valid leader, and the client warnings should stop.

Prevention and Best Practices

• Treat LeaderNotAvailableException as retriable in client code; rely on built-in retries and a sensible metadata.max.age.ms rather than failing fast.
• Avoid producing to a topic in the same instant you create it; let creation settle, or pre-create topics during deployment.
• Run replication factor 3 with min.insync.replicas=2 so a single broker loss never leaves partitions leaderless.
• Spread replicas across racks/zones so correlated failures do not take out all replicas of a partition.
• Do rolling restarts one broker at a time, waiting for under-replicated partitions to return to zero between steps.
• Monitor UnderReplicatedPartitions and offline partition counts so persistent leaderlessness pages you. The free incident assistant can help interpret a --describe dump during a page.

Related Errors

• NotLeaderOrFollowerException — the broker has a leader, but the client’s metadata points at the wrong broker for it.
• UnknownTopicOrPartitionException — the topic-partition does not exist on the contacted broker at all.
• ReplicaNotAvailableException — a replica (not the leader) is temporarily unavailable, usually informational.
• TimeoutException — what a persistent LeaderNotAvailableException eventually becomes if no leader is ever elected.

Frequently Asked Questions

Should I retry on LeaderNotAvailableException? Yes. It is a retriable exception and Kafka clients retry it automatically. In most cases it self-resolves within a metadata refresh cycle.

Why does it always happen right after creating a topic? Topic creation assigns and propagates leadership asynchronously. A produce/fetch that arrives before propagation finishes sees no leader yet, then succeeds on retry.

It is not going away — what now? Persistent occurrences mean partitions are genuinely leaderless. Use kafka-topics.sh --describe --unavailable-partitions to find them, then restore the down brokers that hold their replicas or controller.

Does unclean.leader.election affect this? Yes. With it disabled (the safe default), a partition with no in-sync replica stays leaderless rather than electing a stale replica — protecting data at the cost of availability until an ISR returns.

Is this an authentication or ACL issue? No. It is strictly about partition leadership state, not credentials or permissions.