Is a Kafka health check the same as a Kafka assessment, audit or architecture review?

In practice they overlap. A health check and a cluster assessment review the running cluster and its configuration. A Kafka architecture review looks wider, at how topics, producers, consumers and Connect pipelines fit the business problem. We scope the work to the question you are asking and say so up front.

How long does a Kafka health check take?

One to two weeks from kickoff to walkthrough. Intake takes a day, the review takes days depending on the number of clusters, and the written findings arrive within a week. Estates with several clusters or a Connect-heavy topology take longer, and we confirm the timeline once we know the cluster count.

Do you need access to our production cluster?

No. We need visibility, not hands-on access. Broker and topic configuration, consumer group state, partition and replication layout and metrics history can be exported and reviewed. Read-only access speeds things up, and for regulated environments a configuration export plus a working session with your operators is normally enough.

Does it cover ZooKeeper to KRaft migration?

It covers readiness: whether the cluster, clients, Java versions and tooling can move to Kafka 4.x, and in what order. Apache Kafka 4.0 supports KRaft mode only, so a ZooKeeper-based cluster must migrate before it can upgrade. The migration itself is a separate piece of work, described in our ZooKeeper to KRaft migration guide.

How is this different from monitoring or from AceMQ's Kafka support?

Monitoring reports what is happening now. A health check tells you what will happen under conditions you have not hit yet. Support is an SLA over a cluster your team runs, with a 15-minute emergency response. The health check is a standalone engagement and is also the first step when a cluster moves onto support or managed services, so the work is not repeated.

What does a Kafka health check cost?

It is scoped on the number of clusters and the depth of review, not per broker or per topic. Send the cluster count and your deployment model and we will come back with a written quote within 24 hours.

Kafka Health Check

Kafka Health Check: Find the Failure Before It Finds You

Q: What is a Kafka health check?

A Kafka health check is a structured review of a running cluster against how it is actually used. It covers KRaft readiness, broker and controller configuration, replication and ISR, partition skew, consumer lag, ACLs, TLS and SASL, retention and disk, client configuration and monitoring gaps, and ends in a ranked list of what will fail first and how to fix it.

A Kafka health check is an engineer-led review of a running cluster against how it is actually used: KRaft readiness, broker and controller configuration, replication and ISR, partition skew, consumer lag, security, retention and the monitoring that should have caught the last incident. You get a written report, a prioritised fix list and the reasoning behind each finding.

9 scope areas reviewed on every cluster2 weeks at most from kickoff to walkthrough15 min emergency SLA on the support plan

Available Now

Book a free Kafka Consultation.

Prefer to E-mail?

info@acemq.com

Trusted for Mission-Critical Kafka by Teams in Finance, Healthcare, Defense, Telecom, and More

Is This You?

You probably need this if…

You run ZooKeeper-based Kafka and the move to 4.x has not been scoped

Consumer lag climbs at peak and nobody agrees whether brokers, partitions or clients are to blame

The people who built the cluster have moved on and the topology diagram is out of date

An audit or security questionnaire is asking about ACLs, TLS and authentication on the brokers

Traffic is about to grow: a launch, a new data pipeline, a change data capture rollout

You survived an incident without understanding it, and it could come back

You are choosing between support, managed Kafka and an upgrade and want the facts before the contract

Outcomes

Where you are now, and where you end up

Concrete state changes, not deliverable counts. This is what actually differs about your Kafka estate when the engagement closes.

Before

Nobody can say which Kafka version, mode and client libraries are in play, or what a 4.x upgrade would touch.

After

A written inventory per broker, controller and client group, with the KRaft path and the order of operations laid out.

Before

Replication and durability were set at go-live. The business assumes no data loss, and nobody has checked the settings deliver it.

After

Every topic class reviewed against the loss and availability the business expects, with the gaps listed and costed.

Before

Lag, rebalances and hot partitions show up as incidents, each treated as a one-off.

After

The structural causes named: partition counts, key skew, consumer settings and capacity, each with a fix and an owner.

Before

The team knows the cluster is fragile but cannot rank the risks or size the work.

After

A prioritised plan in three buckets: change now, change before the next growth step, and fine as it is.

Scope

What's covered

KRaft Readiness

Cluster mode, metadata version and controller quorum design, plus the inventory of clients, Connect workers, JVMs and tooling that a move to Kafka 4.x depends on.

Broker and Controller Configuration

Listeners, log directories, heap and page cache, quotas and thread settings read against the hardware and the workload, with every non-default value explained or flagged.

Replication and ISR

Replication factor, min.insync.replicas and producer acks checked as a set, plus unclean leader election, rack or zone awareness, and how often the ISR actually shrinks.

Partition Layout and Skew

Partition counts per topic, key distribution, leader balance across brokers and topics nobody owns. Hot partitions look like a Kafka problem and are usually a design one.

Consumer Lag and Groups

Lag patterns over time rather than a single reading, rebalance frequency, session and poll settings, and which consumer groups cannot keep up with their topic.

ACLs, TLS and SASL

Authorizer configuration, ACL coverage and wildcard grants, TLS on client and inter-broker listeners, SASL mechanism, super users, and where credentials live.

Retention and Disk

Retention and compaction per topic against growth, log-directory headroom, and how long a broker rebuild would take after a disk failure.

Client Configurations

Producer idempotence, acks, retries and batching, consumer commit strategy, and the library versions in use. Most Kafka incidents begin on the client side.

Monitoring and Alerting Gaps

Whether under-replicated and offline partitions, ISR churn, controller health, request latency, disk and consumer lag are measured and paged on, and what would have caught the last incident.

The Engagement

How it actually runs

Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.

Phase 11 day

Intake and Scoping

We agree which clusters are in scope, the Kafka versions and deployment model (self-managed, Strimzi, Amazon MSK, Confluent), and the read-only exports we need. Delivery is remote, guided by your engineers over screen share. We take no access to your environment or code.

You receive

Scope and cluster list
Export checklist: broker and topic configuration, consumer group state, metrics history
Incident history and known concerns collected

Phase 2Days, by estate size

Review

A senior Kafka engineer works through the nine scope areas against your exports and metrics, with your team in the room where a decision needs context. Findings are tested against real consumer lag and replication history, not a generic checklist.

You receive

Inventory per broker, controller and client group
Findings with evidence attached
KRaft and upgrade-path notes

Phase 3Within a week

Written Findings

The report, ranked by what is likely to fail first and under what conditions. Every finding carries the fix, the effort and the risk of leaving it.

You receive

Written report
Prioritised remediation list
Monitoring gap analysis

Phase 4End of week two at most

Walkthrough and Plan

A walkthrough with the engineer who did the work, then a sequenced plan your team can execute or hand to us. Remediation is scoped separately, so the report is useful whoever does the work.

You receive

Findings walkthrough
Sequenced plan: now, before the next growth step, fine as is

Kafka KRaft readiness: what the assessment checks

Apache Kafka 4.0, released on 18 March 2025, supports KRaft mode only. ZooKeeper mode has been removed, and a ZooKeeper-based cluster has to be migrated to KRaft before it can be upgraded to 4.0.x. A KRaft readiness assessment answers one question: what stands between this cluster and a supported 4.x release.

Kafka 4.0 readiness checks and what we inspect
Area	What Apache Kafka 4.0 requires	What we check
Cluster mode	KRaft only. ZooKeeper clusters must migrate to KRaft before upgrading to 4.0.x.	Current mode, metadata version, controller layout, and whether a migration is already in progress.
Clients	Clients, including Kafka Streams and Connect, must be on version 2.1 or higher.	Client libraries per application and per Connect worker, and which of them predate 2.1.
Java	Brokers, Connect and tools require Java 17. Clients and Kafka Streams require Java 11.	JVM versions across the fleet, and the applications that would need a runtime change first.
Controllers	Cluster metadata lives in a quorum of Kafka controllers instead of a ZooKeeper ensemble.	Controller count and placement, dedicated or combined roles, and disk for the metadata log.
Operations	Anything that talked to ZooKeeper has to change.	Runbooks, automation and monitoring that read ZooKeeper, and the ACL authorizer in use.

Rule we hold

Never combine a platform migration with a version upgrade in the same production window. The health check sequences the KRaft move, the version upgrade and any client changes as separate changes.

What the Kafka health check report contains

The report is built to be read by the engineer who runs the cluster and the manager who funds the fixes. This is the outline every report follows. It is a structure, not a client document, and it carries no customer data.

Kafka health check report outline
Section	Contents
1. Summary	The findings most likely to cause an outage or data loss, in plain language, with a risk rating for each.
2. Inventory	Brokers, controllers, Kafka and Java versions, operating system, disks, listeners, Connect workers and client groups.
3. Findings register	One row per finding: severity, evidence, why it matters, the fix, effort and the risk of waiting.
4. KRaft and upgrade path	Readiness against Kafka 4.0, the blocking items, and the order of operations.
5. Monitoring gaps	What is measured and paged today, what is missing, and suggested thresholds.
6. Remediation plan	Three buckets: change now, change before the next growth step, fine as it is.
7. Appendix	Configuration exports and the checks run, so a second engineer can verify any finding.

A report with a hundred undifferentiated observations has not done the hard part, which is ranking them. Ours puts the few findings that matter first and the rest in the appendix.

Where this health check stops

Remote and read-only — We work from your exports and a screen share, guided by your engineers. We do not log in to your environment or touch your code.
No application fixes — We tell you which client settings and patterns to change and why. Your developers make the change.
Hosted services — On Amazon MSK or Confluent Cloud the provider owns broker operations. We review topic design, clients, ACLs and consumer lag, which remain yours.
Remediation is separate — The report stands alone. If you want us to carry out the fixes, that is scoped and quoted as its own piece of work.

Customer Success

Real Kafka Results

See how enterprises trust AceMQ for their most critical Kafka workloads.

All use cases

☁️Support

Producer Timeouts Traced to Controller-Leader Overload

European Hosting Provider

A five-node Kafka cluster serving 60,000 customers was timing out producers under load. The cause was topology, not capacity.

Apache KafkaDockerLinux

Read case study

🔧Support

Recovering Transaction Throughput After a Kafka Rollout

Banking Transaction Platform

Throughput fell from 320,000 to roughly 45,000 transactions per hour after Kafka was introduced. The platform needed 80,000 to prove it could scale.

Apache KafkaKRaftJMeter

Read case study

🏭Consulting

Real-Time Manufacturing Data Ingestion Modernization

Global Automotive Manufacturer

Replacing fragile SQL-trigger-based ingestion with a reliable event-driven architecture for plant-floor data movement and low-latency operations.

RabbitMQMQTTKafka+2

Read case study

📈Assessment

Middleware Architecture Assessment for Financial Trading

European Online Trading Platform

Independent architecture and performance review of RabbitMQ, Kafka, and Redis for an online trading platform.

RabbitMQKafkaRedis

Read case study

🏥Consulting

Replacing Kafka with Debezium + RabbitMQ for Change Data Capture

American National Insurance

American National Insurance replaced a Kafka-based CDC pipeline with a standalone Debezium + RabbitMQ architecture, simplifying operations while maintaining SQL Server change capture with improved message routing flexibility.

KafkaRabbitMQDebezium+1

Read case study

⚙️CVE Patching

Kafka CVE Patching and Compliance Strategy for Global Enterprise

Global Technology Enterprise

AceMQ developed a multi-technology compliance strategy covering CVE patching for Kafka alongside RabbitMQ and IBM MQ deployments, creating a unified vulnerability management approach across the entire enterprise messaging stack.

KafkaRabbitMQIBM MQ

Read case study

💳Support

High-Throughput Kafka and RabbitMQ Support for Global Payments

PagoNXT (Financial Technology)

AceMQ provided ongoing support for PagoNXT's high-throughput payments infrastructure running Kafka and RabbitMQ at 2,500 transactions per second, including load testing validation and architecture optimization.

KafkaRabbitMQ

Read case study

🌐Assessment

Kafka Architecture Assessment and Migration Advisory

Enterprise Organizations

AceMQ's Kafka assessment service evaluates streaming architecture health, identifies operational risks, and provides a structured migration or modernization roadmap for enterprises running or evaluating Kafka.

Kafka

Read case study

FAQ

Questions about Kafka health check

Book a Kafka Health Check

Tell us how many clusters you run and which Kafka version they are on. We will scope the review and come back with a timeline and a written quote within 24 hours.

Get in Touch

Talk to a RabbitMQ Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607

info@acemq.com

66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.