Skip to content

Fix Kafka Consumer Lag

Key idea:

Lag — the count of unprocessed messages in a partition. Diagnose: kafka-consumer-groups.sh --describe. Four causes: (1) consumer is too slow (CPU/DB bottleneck), (2) fewer partitions than consumers in the group (idle consumers), (3) max.poll.interval.ms < processing time (rebalance loop), (4) slow downstream (DB, external API). Fixes: scale up partitions, parallelize, tune max.poll.records.

Below: details, example, related terms, FAQ.

Check your site →

Details

  • kafka-consumer-groups.sh --describe shows lag per partition
  • Partitions > consumers: under-utilization. Partitions < consumers: idle ones
  • max.poll.records default 500 — lower it for heavy processing
  • max.poll.interval.ms default 5min — make it > worst-case processing time
  • Monitoring: Burrow, Cruise Control, Kafka-UI for visual

Example

# Diagnose lag
$ kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
    --group my-consumer --describe

GROUP          TOPIC  PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
my-consumer    orders 0          10000            15000           5000

# Increase partitions (non-reversible)
$ kafka-topics.sh --alter --topic orders --partitions 12

Related

Understanding Kafka Consumer Lag Metrics

Kafka consumer lag is a critical metric that indicates how far behind a consumer is in processing messages. It's essential to monitor this lag to ensure that your application remains responsive and efficient. The lag is defined as the difference between the last produced message offset and the last committed offset of the consumer group.

To effectively monitor consumer lag, you can use the kafka-consumer-groups.sh script. This tool provides insights into the consumer group status, including the current lag for each partition. The command to check the consumer group details is as follows:

kafka-consumer-groups.sh --bootstrap-server  --describe --group 

In the output, look for the Lag column to identify how many messages are unprocessed for each partition. Regularly checking this metric can help you identify trends and take proactive measures to mitigate lag before it affects your application.

Additionally, consider integrating monitoring solutions such as Prometheus and Grafana to visualize consumer lag metrics over time. This can help in spotting potential issues before they escalate into significant bottlenecks.

Optimizing Kafka Consumer Configuration

Optimizing your Kafka consumer configuration is crucial for minimizing consumer lag. Below are some key configurations that can significantly impact consumer performance:

  • max.poll.records: This parameter controls the maximum number of records returned in a single call to poll(). A higher value allows for batch processing of messages, which can improve throughput. Example:
max.poll.records=500
  • fetch.min.bytes: This setting determines the minimum amount of data the server should return for a fetch request. Increasing this value can reduce the number of fetch requests, thus improving throughput. Example:
fetch.min.bytes=1024
  • session.timeout.ms: This parameter defines the time the consumer can be inactive before being considered dead. Lowering this value can lead to more frequent rebalances, while increasing it may allow lag to build up if consumers are slow. Adjust based on your processing time. Example:
session.timeout.ms=30000

By carefully tuning these parameters, you can enhance the performance of your Kafka consumers, thereby reducing consumer lag and improving overall system efficiency.

Common Kafka Consumer Lag Troubleshooting Steps

When dealing with Kafka consumer lag, it’s essential to follow a systematic troubleshooting approach to identify and resolve underlying issues. Here are common steps to consider:

  1. Check Consumer Group Status: Use the kafka-consumer-groups.sh command to monitor the lag and status of your consumer groups. This will help you identify which consumers are lagging and by how much.
  2. Analyze Consumer Performance: Investigate if consumers are experiencing CPU or memory bottlenecks. You can use tools like top or htop to monitor resource consumption on consumer instances.
  3. Evaluate Partition Distribution: Ensure that partitions are evenly distributed among consumers. Use the kafka-topics.sh command to check the number of partitions and their distribution across consumers.
  4. Monitor Downstream Dependencies: If consumers rely on external systems (e.g., databases, APIs), ensure these systems are performing optimally. Slowdowns in downstream systems can directly contribute to consumer lag.
  5. Review Configuration Settings: Revisit your consumer configurations, particularly max.poll.interval.ms and max.poll.records. Adjust these settings based on the processing time of your application.

By following these troubleshooting steps, you can systematically identify and address issues causing consumer lag, ensuring that your Kafka consumers operate efficiently.

Score 0–100Unified site health score
SSL + SecuritySecurity and certificate status
PerformanceResponse speed and caching
SEO Signalsrobots.txt, sitemap, canonicals

Why teams trust us

100
point scale
SSL
SSL + HTTP headers
10+
scoring criteria
Free
no signup

How it works

1

Enter site URL

2

Analyse 10+ factors

3

Get overall score

What is Health Score?

Health Score is a comprehensive assessment of site technical health across 20+ parameters: SSL, security headers, response speed, SEO technical factors, and availability.

Comprehensive Score

20+ parameters in one number: SSL, headers, speed, SEO technical factors.

Detailed Breakdown

Each parameter with explanation — what is checked, what was found, how to fix.

Score Trends

Compare Health Score at different dates — see progress or regression.

Health Monitoring

Set up automated Health Score checks and get notified when the score drops.

Who uses this

Developers

quick pre-release audit

SEO

technical baseline score

Marketers

client site check

Security

header security audit

Common Mistakes

Ignoring red parametersA red parameter is a critical issue. Start fixing those, not the yellow ones.
Only checking homepageIssues may exist on subpages. Check key sections and landing pages.
Not re-checking after fixAfter each fix, rerun the check and verify the score improved.
Treating 80+ as good enoughAim for 95+. Every red item is a risk to SEO or security.

Best Practices

Fix by priorityRed > yellow > blue. Critical issues first.
Check regularlyWeekly Health Score check helps catch degradation before it affects SEO.
Use monitoringConnect an automated HTTP monitor — it will be the first to notice downtime.
Compare with competitorsCheck the Health Score of your nearest competitor — a great benchmark for prioritization.

Get more with a free account

Health Score check history and real-time site health monitoring.

Sign up free

Learn more

Frequently Asked Questions

How many partitions are enough?

Rule of thumb: 10× expected throughput in MBps. 1 partition = ~10 MB/s. 100 MB/s throughput → 10+ partitions.

Can I reduce partitions?

No, it's non-reversible. Create a new topic with fewer, switch producers, migrate consumers.

Compaction vs retention?

Retention: deletes by time (7 days default). Compaction: keeps the latest value per key — useful for event sourcing / state stores.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.