High availability Kafka: the signals that matter, and what changes when agents are on call

Keeping a Kafka cluster highly available usually comes down to watching the right signals before they turn into an incident: under-replicated partitions, controller state, consumer lag trending the wrong way, and the handful of broker and topology metrics that tend to move first when something is about to go wrong. Most teams already track some of this. Fewer have it in one place, and fewer still have caught up with what changes once an AI agent, rather than a human, is the one first responding to an alert.

In this session, Chad Harris, Solutions Architect at Factor House, walks through the operational signals that matter most for keeping Kafka highly available, and how the practice of being on call is shifting as agentic tooling takes on a growing share of first response. He looks at what it takes to give an agent the same operational context a senior engineer would use to triage an incident, and where a human still needs to be the one making the call.

The session closes with a look at governance: an agent querying and acting on production Kafka needs the same authentication, authorization, and audit trail as any other operator, not a separate, looser set of rules.

What the session covers

• The broker, partition, and consumer lag signals worth alerting on for high availability, and the ones that are just noise
• What changes in incident response once an agent can query cluster state directly, rather than a human working from dashboards alone
• Giving an agent enough operational context to triage accurately, and knowing where to draw the line on what it can act on unsupervised
• Keeping the same SSO, RBAC, and audit trail in place for agentic access as for any other operator

This is a technical session aimed at platform engineers, SREs, and anyone responsible for Kafka’s availability day to day.