## 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.

```text
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 LEADER_NOT_AVAILABLE.

- 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

### LEADER_NOT_AVAILABLE 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 LEADER_NOT_AVAILABLE 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/pst_OjSS5kNc83NCDJLLi_EYaA