01
Emergency Incident Response
A broker runs low on disk, leadership flaps cluster-wide, or producers stop flowing. A senior engineer joins a live bridge within 15 minutes with direct access to diagnose — not a ticket acknowledgement.
Redpanda Support
24/7 Redpanda Support with a 15-Minute Emergency SLA
Last reviewed by Scott Sternloff
AceMQ supports Redpanda in production — brokers running low on disk from tiered storage misconfiguration, Raft group leadership flapping under network instability, and client libraries that assume Kafka-specific broker behavior Redpanda doesn't replicate exactly. Every ticket reaches a named senior engineer who already knows your cluster topology.
Support quotes answered within 1 hour, by a senior engineer.
- min emergency SLA
- 15
- across Americas, EMEA, APAC
- 24/7
- enterprise customers
- 160+
- countries served
- 26+
Planning a build, upgrade or migration instead? See AceMQ Redpanda consulting and services.
Customers
Partners
Incident Triage
Redpanda problems we fix every week
These are real symptoms from real Redpanda production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| A broker's local disk fills up despite tiered storage being enabled | Tiered storage upload lag against local retention settings. Local retention configured too high relative to actual upload throughput to object storage means data accumulates locally faster than it's offloaded. | 1–2 hours |
| Partition leadership keeps flapping between brokers | Raft group election timeouts against actual inter-broker network latency and packet loss. Aggressive election timeouts tuned for a stable network will trigger unnecessary re-elections under any network jitter. | 1–3 hours |
| A Kafka client library throws errors or behaves inconsistently against Redpanda | Which specific broker-side behavior the client assumes — often around transactional semantics, certain admin API edge cases, or timestamp handling — that Redpanda implements to spec but not bit-for-bit identically to Kafka. | 2–4 hours |
| Consumer group rebalances repeatedly, throughput collapses during it | Consumer session timeout and heartbeat interval against actual processing time per poll. A consumer whose processing loop exceeds max.poll.interval.ms gets evicted and re-triggers a rebalance for the entire group — this is protocol-level behavior shared with Kafka. | 1–2 hours |
| A WASM data transform fails or stops processing records | Transform runtime logs and resource limits. WASM transforms run in a sandboxed environment per broker core, and a transform that panics or exceeds its memory budget silently stops processing the partition it's attached to. | 2–4 hours |
| Cluster throughput is far below expected despite adequate hardware | Core allocation against seastar's thread-per-core model. Redpanda pins one shard per core, so a mismatch between configured core count, actual CPU allocation, and partition count leaves cores idle while others are saturated. | 1–3 hours |
| Migrating from Kafka and a producer/consumer stopped working post-cutover | Client compatibility mode settings and API version negotiation. Certain Kafka client configurations that rely on broker-specific quirks need adjustment, which is exactly why we run compatibility testing before cutover rather than after. | Same day |
Resolution times reflect typical Redpanda engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
Everything in your Redpanda support contract
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
- 02
Root Cause Analysis
Every P1 closes with a written RCA: what failed, why, the fix applied, and the specific config or code change that prevents recurrence.
- 03
Seastar & Core Tuning
Thread-per-core allocation, partition-to-core alignment, and tiered storage retention tuned against your actual hardware and throughput profile — not generic defaults.
- 04
Client Compatibility Advisory
Testing and guidance on which Kafka client behaviors Redpanda replicates exactly and which need adjustment, before those gaps surface as a production incident.
- 05
Capacity & Storage Reviews
Quarterly reviews of tiered storage upload lag, local disk headroom, and partition growth so you size ahead of demand rather than reacting to a full disk.
- 06
Kafka Migration Support
Migration planning and execution from Kafka to Redpanda, including client compatibility testing, protocol validation, and canary cutover with rollback plans.
Why AceMQ
What you get that you don't get elsewhere
Named Engineers, Zero Cold Start
The same senior engineers stay on your account. They know your cluster topology, your partition layout, and which client libraries you run — so a P1 starts with diagnosis, not twenty minutes of explaining your environment.
No Tier-1 Triage Layer
You reach a senior Redpanda engineer directly by phone, email, or Slack. No help desk collecting information to pass along, no escalation approval process standing between you and someone who can fix it.
We Know Where Redpanda and Kafka Diverge
The Kafka-API compatibility is real but not total. We know precisely which broker behaviors, admin API edge cases, and transactional semantics differ, which matters more when your client libraries assume Kafka specifics.
Genuine Follow-the-Sun Coverage
Engineers across 26+ countries and every time zone. Your 3am leadership-flap incident is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to wake up.
Proactive, Not Just Reactive
Quarterly health checks on tiered storage lag and core utilization, plus shared intelligence across our support base. When a version-specific issue surfaces on one customer's cluster, every affected customer hears about it before it reaches their production.
Honest About the Kafka Comparison
We won't oversell operational simplicity as a reason to migrate if your actual pain points are elsewhere. We diagnose whether Redpanda genuinely solves your specific Kafka operational burden before recommending a migration.
We support Redpanda wherever it's deployed
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
- Redpanda Cloud (BYOC & Dedicated)
- Self-managed Redpanda clusters
- AWS (EC2, EKS)
- Google Cloud (GKE)
- Microsoft Azure (AKS)
- Kubernetes & OpenShift
- Bare metal & on-premise
- Tiered storage to S3/GCS
- Air-gapped / no outbound access
- Mixed Kafka + Redpanda estates
Escalation Path
Your first hour of a Redpanda outage
Every tier reaches a senior Redpanda engineer. There is no tier-1 triage layer to get through.
- 15 minfirst responseEmergencyProduction down, messages not flowing, queue manager failure
- 1 hourfirst responseCriticalSevere degradation, high error rates, approaching capacity
- 4 hoursfirst responseHighPerformance issues, configuration problems, non-critical failures
- Next Dayfirst responseStandardQuestions, guidance, best practices, non-urgent improvements
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
T+Elapsed15:00
15-minute P1 response, 24/7.
A response time, not a resolution time.
- T+00:00Paged
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
- T+15:00Live
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
- T+30:00If needed
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
- AfterEvery P1
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Pricing
What does AceMQ Redpanda support cost?
AceMQ Redpanda support contracts typically run $24,000–72,000 a year, depending on SLA level, scope (number of clusters or nodes, and environments) and deployment (self-managed, cloud-managed or Kubernetes).
| What moves the price | How it changes the contract |
|---|---|
| SLA level | Business-hours cover costs less than 24/7 cover with a 15-minute emergency response. |
| Scope | More clusters or nodes, and more environments, make a larger contract. |
| Deployment | Self-managed, cloud-managed and Kubernetes estates need different amounts of hands-on work. |
Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount.
Support In Practice
Redpanda problems we've already solved
Redpanda support, remediation and assessment work from AceMQ. Each card links to the full write-up: the cluster, what AceMQ diagnosed or changed, and the result.
Apache Flink Streaming Readiness Assessment
Smart Grid Technology Provider
Evaluating whether a proposed streaming workload belongs on Flink, and what the exactly-once, state, and operational requirements will really cost.
Apache Flink
Apache Kafka
Kubernetes
RedpandaRedpanda Tiered Storage Assessment
Connected Device Platform Provider
Designing tiered storage for long retention so historical data lives in object storage without local disk dictating how long you can keep it.
RedpandaApache KafkaKubernetes
Apache SparkRedpanda Broker Latency Remediation
Online Gaming Platform
Resolving produce and consume latency spikes traced to Raft leadership imbalance, disk saturation, and partition distribution across brokers.
RedpandaKubernetesApache KafkaRedpanda Production Support
Healthcare Analytics Provider
Named-engineer 24/7 support for Redpanda clusters covering node recovery, consumer lag incidents, upgrades, and client-side failures.
RedpandaApache KafkaKubernetesRedpanda Migration from Apache Kafka
Global Payments Processor
Migrating from Kafka to Redpanda with client compatibility testing, ACL and schema registry translation, and a staged cutover per topic.
RedpandaApache KafkaKubernetesApache Flink
Support options
Four tiers of Redpanda support.
AceMQ offers Redpanda support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for clusters your team runs, proactive monitoring that catches disk, leadership and CVE problems first, managed Redpanda on your own infrastructure, and fully managed Redpanda on AceMQ infrastructure. Self-managed clusters and, above the managed layer, Redpanda Cloud are covered in all four.
- Tier 1
Redpanda 24/7 Support & Incident Management
You run it, we back you up
- 15-minute P1 response, 24/7, by phone, email or Slack
- Diagnosis across brokers, Tiered Storage and Kafka client behaviour
- Written root-cause analysis after every P1
Best for: Teams that run Redpanda themselves and need senior cover at 3am.
- Tier 2
Redpanda 24/7 Support with Proactive Monitoring
You run it, we watch it with you
- Scheduled reviews of node sizing, core allocation and partition layout
- CVE and known-bug alerts for your exact Redpanda release
- Tiered Storage upload lag and local disk headroom checks
Best for: Clusters where a full disk or a leadership shuffle is not an acceptable surprise.
- Tier 3
Managed Redpanda on Your Infrastructure
We run it in your cloud or data centre
- AceMQ runs day-2 operations and holds the pager
- Runs in your cloud account, Kubernetes cluster or air-gapped site
- Rolling upgrades and node replacement rehearsed before they are needed
Best for: Regulated estates that must keep streaming data inside their own boundary.
- Tier 4
Fully Managed Redpanda on AceMQ Infrastructure
We host it and run it, as a service
- Hosted and operated by AceMQ, sized to your workload
- Kafka-protocol endpoints for your existing clients
- Upgrades and capacity managed to an agreed plan
Best for: Teams that want Kafka-protocol streaming without owning a cluster, a cloud account or a rota.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Redpanda day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for Redpanda
Everything else AceMQ does for Redpanda.
Support is one part of what AceMQ does for Redpanda. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
- ConsultingRedpanda consulting and services
- LifecycleEnd-of-life software support
- Enterprise supportOpen source support across your whole stack
- GuideRedpanda guide
Support for the rest of your stack
Messaging & Streaming
- RabbitMQ supportMessaging & Streaming
- Apache Kafka supportMessaging & Streaming
- IBM MQ supportMessaging & Streaming
- ActiveMQ supportMessaging & Streaming
- Azure Service Bus supportMessaging & Streaming
- Amazon SQS supportMessaging & Streaming
- Google Cloud Pub/Sub supportMessaging & Streaming
- Apache Pulsar supportMessaging & Streaming
- Message Queuing supportMessaging & Streaming
Databases & Caching
Search & Analytics
Lakehouse & Compute
Observability & Monitoring
Data Integration
Cloud & Containers
API Management
See support for all 51 technologiesShow fewer
Related services
What does AceMQ Redpanda support include?
Our Redpanda support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, seastar and core tuning, client compatibility advisory, quarterly capacity reviews, and Kafka migration support. Every ticket is handled by a named senior engineer — there is no tier-1 triage layer and no per-incident charge.
Do you support Redpanda Cloud as well as self-managed clusters?
Yes. We support Redpanda Cloud (BYOC and Dedicated) alongside self-managed deployments on Kubernetes, VMs, or bare metal. The managed variant removes infrastructure operations but not client compatibility, partition design, or WASM transform issues — those are still where most incidents originate.
Can you fix a Kafka client that behaves differently against Redpanda than it did against Kafka?
Yes. This is one of the most common Redpanda support requests we get. Redpanda implements the Kafka protocol to spec, but certain broker-side behaviors — particularly around transactional edge cases, admin API responses, and timestamp handling — aren't bit-for-bit identical. We identify the specific divergence and either adjust the client configuration or the Redpanda-side setting causing it.
How fast do you respond to a Redpanda production outage?
P1 emergencies — a broker down, leadership flapping cluster-wide, or producers not flowing — 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, not best-effort targets.
We're migrating from Kafka to Redpanda. Can you help?
Yes. We plan and execute Kafka-to-Redpanda migrations, including client compatibility testing before cutover — not after — protocol-level validation, and a canary cutover with a rollback plan. We'll also tell you honestly if your specific Kafka pain points won't actually be solved by the migration.
Do you support WASM data transforms?
Yes. We troubleshoot WASM transform failures, including transforms that panic or exceed their per-core resource budget and silently stop processing a partition, which is a Redpanda-specific failure mode with no Kafka equivalent.
What is Redpanda, and how does it differ from Apache Kafka?
Redpanda is a streaming data platform from Redpanda Data that implements the Kafka API, so existing producers, consumers and Kafka Connect pipelines work against it without code changes. Underneath it is different: written in C++ with a thread-per-core architecture, no JVM and no ZooKeeper, and Raft-based replication built in. That changes what operations look like. There is no heap to tune and no controller quorum to run separately, but partition limits are tied to cores and memory, Tiered Storage moves older data to object storage, and the upgrade path moves one release at a time. Our support covers the Redpanda-specific parts as well as the Kafka-compatible surface your applications see.
What response time can we expect for a critical Redpanda outage, and what does support cover after it?
A P1, meaning a cluster down, under-replicated partitions blocking producers, or data loss suspected, gets a senior engineer on a live call within 15 minutes, around the clock. After the incident you get a written root cause analysis. Between incidents the contract covers what prevents downtime: monitoring and alerting on disk headroom, replication and consumer lag, review of the deployment on Kubernetes or bare metal, sizing for partition counts and Tiered Storage, and rehearsed sequential upgrades so the cluster stays inside Redpanda's 12-month support window. Redpanda Cloud and BYOC clusters on AWS, Azure or GCP are covered for everything above the managed layer, which is where most pipeline problems actually live.
Can we work with AceMQ on Redpanda without a long contract?
Yes. AceMQ works on Redpanda 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.
How much does AceMQ Redpanda support or consulting cost?
Every AceMQ proposal is tailored to your requirements: your Redpanda 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 Redpanda is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Your Redpanda Cluster Shouldn't Depend on Nobody Touching It
Reactive cover, proactive reviews, or AceMQ running Redpanda for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
A senior Redpanda engineer, not a sales queueQuote requests answered within 1 hourAd hoc engagements or an annual partnership
Production incident right now?Email a Redpanda Architect
Get in Touch
Talk to a Redpanda Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.