24/7 Apache Kafka Support and SLAs

Confluent supports Confluent Platform and Confluent Cloud under its own subscriptions. AWS supports Amazon MSK as a service, which covers the managed infrastructure rather than your topic design, consumers or clients. The Apache Kafka project itself offers community mailing lists, not a support contract. Independent providers such as AceMQ support open-source Apache Kafka, Confluent Platform and MSK estates under one 24/7 contract with a 15-minute emergency SLA.

Yes. Apache Kafka commercial support does not require a Confluent subscription, and a support contract for Apache Kafka can come from an independent provider. AceMQ supports Apache Kafka as released by the project, on the version you run, including clusters still on ZooKeeper, with incident response, root cause analysis, upgrade planning and KRaft migration support.

Yes. The Apache project maintains only its three most recent releases, which as of October 2026 are Kafka 4.4, 4.3 and 4.2. Every 3.x and 2.x line, and Kafka 4.0 and 4.1, receive no upstream fixes. AceMQ supports the version you are actually running, advises on which CVEs affect it, and plans the upgrade path, including the ZooKeeper to KRaft migration that Kafka 4.0 made mandatory. Where you need security patches on a version you cannot yet leave, AceMQ's OSSeva platform backports CVE fixes to Apache Kafka 2.8.x through 3.7.x.

Kafka support covers 24/7 emergency incident response with a 15-minute SLA, written root cause analysis on every P1, throughput and latency tuning, security and CVE advisory, Kafka Connect and Schema Registry coverage, and upgrade or migration support. Every ticket is handled by a named senior engineer assigned to your account. There is no first-line triage layer and no per-incident charge.

All three. We support self-managed Kafka, Amazon MSK and MSK Serverless, and Confluent Platform and Confluent Cloud. Managed Kafka removes broker provisioning but leaves you the parts that cause most incidents — partition design, consumer group behavior, client configuration, and topic-level retention. Those are exactly where our diagnostic time goes, and they are outside what provider support typically covers.

P1 emergencies — brokers down, a partition with no leader, a consumer group stuck in perpetual rebalance — get a 15-minute first response with a senior engineer joining a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual commitments, not best-effort targets.

Yes, and it is one of the most common things we are called for. Unexplained lag is usually one of four things: a rebalance loop caused by processing time exceeding max.poll.interval.ms, partition-to-consumer skew from a poor key distribution, a slow downstream dependency inside the poll loop, or a hanging transaction pinning the last stable offset. We instrument the consumer to identify which before changing any configuration.

Yes. We plan and execute ZooKeeper-to-KRaft migrations, including the dual-write bridge phase, controller quorum sizing, and the version gates that have to be cleared before migration can start. We also do rolling version upgrades with inter.broker.protocol.version staging so clients are never forced into a lockstep deploy.

Yes, both are inside the standard contract. Connect worker rebalances, failed tasks, sink connector backpressure, and dead-letter queue design are common ticket sources. So are Schema Registry compatibility failures during rolling producer deploys, where a schema change is accepted by the registry but breaks consumers still running the previous version.

Yes, and the design question comes before the tooling. MirrorMaker 2 and Cluster Linking replicate differently, and neither gives you an RPO by itself — offsets, consumer group state and topic configuration all have to be part of the plan or a failover leaves consumers reprocessing or skipping. We review the replication topology, what actually fails over versus what has to be rebuilt, and the recovery procedure end to end. Active-active, active-passive and stretch clusters each carry different failure behaviour under partition, and the right answer depends on whether your workload can tolerate duplicate delivery.

Kafka is not a database and backing it up like one goes wrong. Durability comes from replication factor, min.insync.replicas and acks together — a replication factor of three with min.insync.replicas of one will lose data on a broker failure regardless of your backup. Beyond that, retention and tiered storage decide what is actually recoverable and for how long, and topic-level overrides routinely drift from the cluster default. Support covers reviewing that configuration against the durability you believe you have, plus the offset and schema state you would need to reconstruct a cluster.

Both. A security review covers SASL mechanism and TLS configuration, ACLs and whether the principals map to what teams actually need, ZooKeeper or KRaft controller exposure, and inter-broker encryption. On monitoring, the signals that predict incidents are under-replicated and offline partitions, ISR shrink rate, request handler idle ratio, consumer lag trend by partition rather than aggregate, and controller election frequency. Alerting on broker liveness alone finds out after users do. We define the thresholds and review what you already collect in Prometheus, Grafana, Datadog or whatever is in place.

Kafka support services are a contract for technical support on a Kafka cluster you run: SLA-backed incident response from Kafka experts, root cause analysis, performance tuning, upgrade planning across the Kafka lifecycle, and reviews that prevent downtime and data loss before they happen. Apache Kafka is a distributed event streaming platform from the Apache Software Foundation, and the project itself offers mailing lists, not a contract. Support covers the brokers and controllers, and in practice also the things around them that fail more often: producers and consumer groups, Kafka Connect, Kafka Streams applications, Schema Registry, and the data pipelines that depend on them. Good support also leaves runbooks behind, so the next incident is shorter.

Kafka 4.0 removed ZooKeeper entirely, so every 4.x cluster runs in KRaft mode, and a 3.x cluster has to be migrated to KRaft on a late 3.x release before it can move to 4.x. Kafka 4.0 also dropped support for the oldest client protocol versions, moved to newer Java requirements, and made the new consumer group rebalance protocol generally available. We support both lines. For 3.x clusters, which the project is phasing out, that means incident response and mitigation now, and a rehearsed KRaft migration and upgrade when you are ready.

They solve different problems. Managed Kafka services such as Confluent Cloud or Amazon MSK run the brokers for you, which removes infrastructure work and introduces a degree of vendor lock-in and a cost that scales with throughput. They do not operate your producers, consumers or stream processing, which is where most incidents start. Independent support keeps the streaming platform under your control, on premises or in your own cloud account, and adds round-the-clock support from engineers who can see the whole path. Many teams use both: a managed service for the brokers, and a support partner for everything that talks to them.

Usually at one of four moments: an audit or customer contract requires a support agreement for production Kafka; the team has no dedicated Kafka SRE and incidents depend on one person; a Kafka 3.x to 4.x upgrade or ZooKeeper to KRaft migration is coming; or the organisation is leaving Confluent or MSK support and wants cover that does not depend on the platform.

For Apache Kafka and the community components, yes: AceMQ supports Confluent Platform deployments directly. Check one thing first. Confluent Platform's enterprise features, such as Control Center and role-based access control, run under Confluent's commercial licence, so dropping the subscription can mean losing those features rather than just changing who answers the phone. We help map exactly which components you use before you decide.

Kafka enterprise support is a paid contract with defined response times for a production Kafka estate, as opposed to community help from mailing lists and forums. Confluent (now part of IBM) provides it for Confluent Platform and Confluent Cloud, AWS covers the Amazon MSK service, and independent providers such as AceMQ support open-source Apache Kafka, MSK and Confluent Platform together. Compare them on which versions are covered, whether clients and Connect are in scope, and who answers a P1. Ours is a 15-minute first response, 24/7, from a named senior engineer.

Start with scope, then response. Check which Kafka versions are covered, including ones the Apache project no longer patches, whether clients, Kafka Connect and Schema Registry are in scope, whether Amazon MSK and Confluent Platform clusters are covered, and who answers a P1 and how fast. A Kafka support provider that follows your estate, not one product, can cover a mixed fleet under one contract. Ours is a 15-minute first response, 24/7, from a named senior engineer.

IBM announced the acquisition on 8 December 2025 and completed it on 17 March 2026. Existing Confluent contracts continue as signed, and renewals are now a conversation with IBM, so many teams are checking whether they need Confluent's platform or only support for Apache Kafka. Apache Kafka itself is unchanged. The options are compared in Confluent alternatives after the IBM acquisition.

Yes. Coverage runs from business hours through to 24/7 with a 15-minute emergency response, and you can move up a coverage level when a workload becomes critical without re-onboarding: the engineers already know your clusters.

Support is an SLA over clusters your team runs: you hold the pager and call us when something breaks. Managed Kafka services means AceMQ runs the clusters on your infrastructure or on AceMQ infrastructure, owning monitoring, patching, upgrades, capacity and on-call. Teams with a platform team that wants to keep ownership choose support; teams that want Kafka to stop being their problem choose managed services.

Yes. AceMQ works on Apache Kafka in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

Every AceMQ proposal is tailored to your requirements: your Apache Kafka environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Apache Kafka is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.