Kafka Health Check
Find the production risks before they find you.
Most Kafka estates grow organically: topics created under deadline pressure, defaults never revisited, monitoring inherited from whatever the first team set up. The health check is a structured pass over the whole platform by an engineer who has seen where these things break.
What we review
- Broker and cluster configuration — replication factors,
min.insync.replicas, unclean leader election, rack awareness, storage headroom and retention against actual growth. - Topic and partition design — partition counts against measured throughput and consumer parallelism, key distribution and hot partitions, compaction settings on topics that need them (and on topics that should not have them).
- Consumer groups — rebalance behavior, assignor strategy, commit patterns, lag measured in time rather than records, poison-pill handling.
- Producers and delivery guarantees — acks and idempotence settings, retry behavior, transaction usage where it matters and where it is unnecessary cost.
- Monitoring and alerting — whether the signals that precede real incidents (ISR shrink, metadata lag, disk latency, time lag per group) are actually alarmed, and whether anyone would believe the page.
- Upgrade posture — how far behind current the cluster is, ZooKeeper-to-KRaft status, and what the path to supported versions looks like.
What you get
A written findings-and-fixes report, ranked by production risk: what is likely to page you, what is costing you capacity or money, and what is fine and should be left alone. Each finding names the change, the reason, and the order to do it in. We walk your team through the report and stay available for the fixes — done by us, by you, or together.
What it is not
Not a sales audit. The report is not shaped to manufacture follow-on work, and "this part is healthy" appears wherever it is true.