How to Monitor Kafka Consumer Lag: CLI, Exporters, Alerts (2026)

Short answer: Consumer lag is the gap between the latest offset written to a partition (log-end-offset) and the offset your consumer group has read (current-offset). Check it ad-hoc with kafka-consumer-groups.sh --describe; monitor it continuously with Kafka Lag Exporter (Prometheus) or Burrow; and alert on lag growth rate sustained over 15–30 minutes — not absolute lag, which pages you for healthy batch consumers and misses slow leaks.

What lag actually means

Each partition is an ordered log. Producers append to the end; consumers track their read position. Lag per partition = log-end-offset − current-offset. Per group, you typically sum across partitions. Lag exists by design — consumers are always slightly behind. The question monitoring must answer is not "is there lag?" but "is lag growing, and how long until the consumer catches up?"

Ad-hoc check (the CLI you already have)

bin/kafka-consumer-groups.sh --bootstrap-server broker:9092 --describe --group orders-consumer

# GROUP           TOPIC   PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG   CONSUMER-ID
# orders-consumer orders  0          154832          154900          68    consumer-1-/10.0.1.4
# orders-consumer orders  1          98211           102450          4239  consumer-2-/10.0.1.5  ← watch this

Reading it: lag concentrated in specific partitions (not spread evenly) usually means a stalled instance or a hot key — not general slowness. Empty CONSUMER-ID means no active member owns that partition: the group is broken, not slow.

Related guideKafka Monitoring: The Complete 2026 Guide→

Continuous monitoring: the two standard tools

# kafka-lag-exporter (helm/values sketch)
clusters:
  - name: prod
    bootstrapBrokers: "broker:9092"
# exposes: kafka_consumergroup_lag{cluster,group,topic,partition}

Platform agents (Confluent, Datadog, Guance DataKit) read the same offsets and add correlation — lag next to the consumer application's traces and deploy markers, which is what turns "lag is growing" into a root cause.

Alerting: rate, not level

Absolute-lag alerts (lag > 10,000) misfire in both directions: a batch consumer legitimately holds 100K lag and drains it hourly (false page), while a payment stream leaking 200 messages/minute never crosses the threshold (missed incident). The correct patterns:

Related guideKafka Integration→

# 1. Lag growing continuously for 30m — the real incident shape
deriv(sum by (group) (kafka_consumergroup_lag)[30m:1m]) > 0

# 2. Estimated time-to-drain exceeds budget (needs consume-rate metric)
sum by (group) (kafka_consumergroup_lag)
  / sum by (group) (rate(kafka_consumer_fetch_manager_records_consumed_total[10m])) > 900

# 3. Partition assigned to no consumer (group breakage)
kafka_consumergroup_lag > 0 unless kafka_consumergroup_current_offset

Rule 2 converts lag into time — "this group is 15 minutes behind" — which is the unit your SLA and your users actually care about.

Diagnosing growing lag: the decision order

1. Is one partition hot? Lag concentrated in 1–2 partitions → skewed key distribution or a stuck instance. Fix: repartition, or restart the stuck member.
2. Is the group rebalancing repeatedly? Check rebalance_rate; causes: slow message processing exceeding max.poll.interval.ms, GC pauses, or instance crash loops.
3. Is the consumer simply slower than the producer? Compare produce rate vs consume rate — if permanently mismatched, scale consumer instances (up to partition count) or optimize processing.
4. Is the broker slow? Fetch request latency and UnderReplicatedPartitions from the broker side — sometimes the consumer is the victim, not the cause.

FAQ

Q: What is consumer lag in Kafka?
Consumer lag is the number of messages written to a partition that a consumer group has not yet read — log-end-offset minus current-offset, summed across partitions. Some lag is normal; continuously growing lag means consumers are falling behind producers and processing delays are accumulating.

Q: How do I check Kafka consumer lag?
Run kafka-consumer-groups.sh --bootstrap-server <broker> --describe --group <group> and read the LAG column. For monitoring (history + alerts), deploy Kafka Lag Exporter or Burrow and track lag as a time series — CLI snapshots cannot alert.

Q: What is a "normal" consumer lag value?
There is no universal number — it depends on message rate and consumer design. A batch consumer may healthily hold 100K messages of lag; a real-time payment stream may be unhealthy at 500. Alert on lag growth rate sustained over 15–30 minutes, or on estimated time-to-drain, rather than absolute values.

Q: Why is my consumer lag growing?
The four usual causes, in diagnostic order: a stalled or crashed consumer instance (lag concentrated in its partitions), repeated rebalancing (processing slower than max.poll.interval.ms), consume rate structurally below produce rate (under-scaled consumer group), or broker-side slowness (fetch latency, under-replicated partitions).

Q: Burrow vs Kafka Lag Exporter — which should I use?
Use Kafka Lag Exporter if you're Prometheus-native and comfortable writing rate-based PromQL alerts. Use Burrow if you want evaluated lag status (OK/WARN/ERR over sliding windows) that gracefully handles bursty producers — its HTTP API integrates with any monitoring stack. Many teams run Lag Exporter for metrics and reserve Burrow's status checks for paging.

---

Sources: Apache Kafka documentation (consumer groups, offsets), Kafka Lag Exporter and Burrow project documentation. Verified 2026-08-07.