Redpanda Support

24/7 Redpanda Support with a 15-Minute Emergency SLA

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.

Senior Redpanda engineers on call right now — 24/7/365
15 min emergency SLA24 /7 global coverage130 + enterprise customers26 + countries served

Trusted for mission-critical Redpanda by teams in finance, healthcare, defense, and telecom

Escalation Path

Your first hour of a Redpanda outage

Most vendors publish an SLA number. This is what actually happens, minute by minute, when you page a senior AceMQ engineer.

T+0

You page us

Phone, email, or Slack — any channel reaches the on-call senior engineer directly. No web form, no tier-1 queue.

T+15

Named engineer live

A senior engineer who already knows your environment joins a live bridge. Zero cold-start, no re-explaining your topology.

T+30

Root cause isolated

Direct broker access, log and metric review, and a working hypothesis with a rollback plan before we touch anything.

Post

Written RCA

Documented root cause, the fix applied, and the prevention steps — delivered after every P1, not just when asked.

Response Times

SLA tiers, contractually guaranteed

Every tier reaches a senior Redpanda engineer. There is no tier-1 triage layer to get through.

P1 — Emergency
15 min

Production down, messages not flowing, cluster or broker failure

P2 — Critical
1 hour

Severe degradation, rising error rates, approaching capacity limits

P3 — High
4 hours

Performance issues, configuration problems, non-critical failures

P4 — Standard
Next day

Questions, guidance, best practices, non-urgent improvements

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.

A broker's local disk fills up despite tiered storage being enabled
What we check firstTiered 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.
Typical resolution1–2 hours
Partition leadership keeps flapping between brokers
What we check firstRaft 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.
Typical resolution1–3 hours
A Kafka client library throws errors or behaves inconsistently against Redpanda
What we check firstWhich 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.
Typical resolution2–4 hours
Consumer group rebalances repeatedly, throughput collapses during it
What we check firstConsumer 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.
Typical resolution1–2 hours
A WASM data transform fails or stops processing records
What we check firstTransform 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.
Typical resolution2–4 hours
Cluster throughput is far below expected despite adequate hardware
What we check firstCore 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.
Typical resolution1–3 hours
Migrating from Kafka and a producer/consumer stopped working post-cutover
What we check firstClient 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.
Typical resolutionSame day

Resolution times reflect typical Redpanda engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.

Not on the list? Tell us what's breaking
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.

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.

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.

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.

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.

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.

Kafka Migration Support

Migration planning and execution from Kafka to Redpanda, including client compatibility testing, protocol validation, and canary cutover with rollback plans.

Anywhere You Run It

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 clustersAWS (EC2, EKS)Google Cloud (GKE)Microsoft Azure (AKS)Kubernetes & OpenShiftBare metal & on-premiseTiered storage to S3/GCSAir-gapped / no outbound accessMixed Kafka + Redpanda estates
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.

FAQ

Redpanda support questions

Your Redpanda Cluster Shouldn't Depend on Nobody Touching It

Whether you need emergency response tonight or a support contract that catches disk pressure and leadership instability before they become an outage, AceMQ staffs every engagement with a named senior Redpanda engineer. Support quotes returned within 24 hours.

Get in Touch

Talk to a Support Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607
info@acemq.com
66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.

We respond within 1 business day.

Pick a time that works — no pressure, no pitch. Just 30 minutes with an expert.

We respond within 1 business day.