Almost nobody reads the scope clause until the incident that falls outside it.
Response times get compared carefully; scope rarely does. Yet scope is what decides whether the contract helps at 3am, because most Kafka incidents have a cause that is not, strictly speaking, Kafka.
What Is Normally In
Broker and cluster operations. Availability, partition and replica health, controller and quorum state, storage pressure, and the reasons a broker will not rejoin.
Consumer and producer behaviour. Where most real incidents actually live — lag, rebalances, offset commits, producer timeouts under back-pressure.
Performance diagnosis. Why throughput dropped, why latency moved, whether the cluster is at a genuine limit or misconfigured for the workload.
Upgrades and version guidance. What changes between releases and how to sequence a rolling upgrade — including the ZooKeeper to KRaft migration, which is a project rather than a patch.
Escalation with a response commitment. Defined by severity, in writing. Note that a response commitment is not a resolution commitment — the distinction is set out in evaluating a Kafka support SLA.
What Is Normally Out
Your application code. A provider can tell you a consumer is not committing offsets, or that a producer's retry logic is creating duplicates, and explain what correct looks like. Rewriting your service is your work. That is a reasonable boundary, but be clear it exists.
The infrastructure underneath. Hosts, disks, network, Kubernetes. A provider will identify that storage latency is causing the problem; fixing the storage is usually someone else's job.
Third-party tooling. Monitoring stacks, deployment pipelines, and connectors nobody in the contract wrote.
The data itself. Support covers the transport, not whether the messages mean what your business thinks they mean.
The Grey Areas That Actually Bite
These are the incidents where scope gets argued, and they are common rather than exotic.
Kafka Connect failing because a sink is slow. The symptom is a Connect task failure. The cause is a database. Whose problem?
A rebalance storm triggered by pod eviction. Kubernetes moved the consumers. Kafka behaved exactly as designed. The outage was still real.
Producer timeouts during a network degradation. Kafka is healthy, the clients cannot reach it reliably.
Schema Registry compatibility failures mid-deploy. The registry accepted a schema that broke consumers still running the previous version.
In each case a good provider helps regardless and sorts out attribution afterwards. A poor one uses the seam to decline. You cannot tell which you have from the contract text — which is why the exercise below is worth doing.
How to Find the Real Boundary Before You Sign
Take three incidents you have genuinely had. Describe them to the provider and ask, for each: covered, out of scope, or grey?
The answers tell you more than any scope clause, and the manner of answering tells you more still. A provider who engages with the specifics — including saying honestly where they would stop — is one who will engage during an incident. A provider who retreats to the contract language before you have even signed will do the same at 3am.
Two more worth settling explicitly: whether Kafka Connect and Schema Registry are in scope, and whether advisory questions such as "is this partitioning sensible?" are included or billable. If design review is billable, people stop asking, and you lose the cheapest incident prevention available.
AceMQ provides Apache Kafka support with Connect and Schema Registry inside the standard contract and advisory access included. If you want to run the three-incident test on us, get in touch.
FAQ
What does a Kafka support contract normally include?
Broker and cluster operations, consumer and producer behaviour, performance diagnosis, upgrade guidance, and escalation with a response commitment by severity.
What is usually excluded?
Your application code, the infrastructure beneath Kafka, third-party tooling, and anything about the data rather than its transport.
Where do contracts get argued?
At the seams — Connect failing on a slow sink, rebalances caused by pod eviction, producer timeouts during network degradation. Settle these before signing.
Is Kafka Connect and Schema Registry included?
It varies — included, separately priced, or excluded. Both are common ticket sources, so ask explicitly.
Does support cover architecture and design?
Sometimes advisory, sometimes billable, sometimes not at all. If design questions are billable, people stop asking — losing the cheapest prevention available.
How do I get the boundary written down?
Describe three incidents you have actually had and ask, for each, whether it would be covered. More revealing than the scope clause itself.
