Analytics consent
We use Google Analytics for basic traffic stats. kafkahelper stores no cluster data, config input, or personal data in the app.
Broker validator
Use this page for `server.properties`, broker defaults, and cluster-level settings. The rules focus on replication safety, internal topic resilience, retention posture, and capacity defaults.
Critical
5
Warnings
4
Info
0
Topics created without an override will not have enough replicas for durable production use.
Recommended change: Raise `default.replication.factor` to at least `3` for production clusters with enough brokers.
Why: Topic creation paths are rarely perfectly controlled. Safe defaults stop one missing flag from creating a fragile topic.
`acks=all` will still succeed with only one in-sync copy available.
Recommended change: Use `min.insync.replicas=2` for replicated production topics when replication factor is at least 3.
Why: This is the guardrail that turns producer acknowledgements into real redundancy instead of a false sense of safety.
Out-of-sync replicas are allowed to become leader.
Recommended change: Set `unclean.leader.election.enable=false` unless you have explicitly chosen availability over data safety.
Why: An out-of-sync leader can come online without all acknowledged writes, which makes earlier success responses impossible to trust.
The internal offsets topic is not replicated strongly enough.
Recommended change: Raise `offsets.topic.replication.factor` to `3` where cluster size allows it.
Why: Consumer group stability depends on the offsets topic. Weak replication here translates directly into operational instability.
Kafka transactions rely on an internal topic that is configured with weak redundancy.
Recommended change: Raise `transaction.state.log.replication.factor` to `3` if transactions are part of your platform contract.
Why: Exactly-once features are only as resilient as the internal log storing their transaction state.
The broker has fewer I/O workers than a typical production starting point.
Recommended change: Review disk count, replica traffic, and CPU availability, then raise `num.io.threads` if the broker is busy.
Why: I/O threads gate log append and replica fetch work, so undersizing them can cause queueing long before the disks are truly full.
The broker may struggle to keep up with concurrent produce and fetch traffic.
Recommended change: Increase `num.network.threads` after checking connection counts and request handler idle time.
Why: Network threads often become the first bottleneck on busy brokers because every client and replica request passes through them.
Typos and one-off experiments can create real topics with whatever defaults happen to be configured.
Recommended change: Disable automatic creation in production and provision topics intentionally.
Why: Unexpected topics are easy to miss and often inherit unsafe partition and replication defaults.
Data may age out before downstream consumers or replay workflows can catch up.
Recommended change: Validate that your slowest consumers and recovery procedures comfortably fit inside the retention window.
Why: Short retention is not wrong by itself, but it should be a deliberate cost decision rather than an unnoticed default.
