24/7 RabbitMQ Support for Enterprises

Community support means public GitHub issues and mailing lists on the newest release only, with no response commitment. Commercial support adds guaranteed response times, security patch guidance, and an engineer accountable for your cluster. AceMQ answers P1 incidents in 15 minutes, covering everything from quorum queue migrations and performance tuning to Erlang version compatibility and plugin issues on mission-critical deployments.

Both. Open-source RabbitMQ under the Mozilla Public License is fully supportable. You do not need to buy Tanzu RabbitMQ to get an SLA-backed engineer on your cluster, and a large share of the estates we cover are open-source builds. Where a commercial licence genuinely helps, we say so and can source it; where it would not change anything for you, we say that too.

A named senior engineer rather than a ticket queue, a contracted response time for every severity, CVE guidance and patching advice, upgrade and migration planning, and proactive health checks against the cluster rather than after an incident. There is no tier-1 triage layer to get past: the first person who reads your ticket is the person who can fix it.

It is priced on the size of the estate and the response commitment, not on seats. Two inputs set the number: how many nodes or licensed cores you run, and the SLA tier you need, from business hours up to 24/7 with a 15-minute emergency response. Commercial licensing from Broadcom carries a 72-core minimum; AceMQ is the only provider able to license below it, which matters for smaller clusters. Quotes come back within 24 hours against your actual broker count, so the fastest route to a real figure is the quote form rather than a published price list that would not match your estate.

Several vendors sell a 24/7 tier; the question to ask is what 24/7 means in the contract. AceMQ's 24/7 tier commits to a 15-minute response on P1 incidents at any hour, with a named senior engineer rather than a rotation of generalists, and it covers open-source RabbitMQ as well as Tanzu RabbitMQ. If a provider quotes 24/7 without a response-time number for after-hours P1s, it is a marketing label rather than a service level.

Mostly on three axes. Distribution: open-source RabbitMQ, the commercial Tanzu distribution, or both. Who is on the other end: a ticket queue with tiers, or a named engineer. And scope: break-fix only, or health checks, upgrade planning and CVE guidance included. AceMQ contracts include all three: a named engineer, both distributions, and proactive work between incidents.

Coverage is tiered by response time rather than by feature, so nothing is withheld from lower tiers. Every tier includes issue resolution by senior engineers, health checks, upgrade planning and CVE guidance; the tiers differ in guaranteed first response and hours of cover, from business hours through to 24/7 with a 15-minute emergency SLA.

Our guaranteed response times are often significantly faster than standard tier-1 industry support, and you get direct access to seasoned architects rather than generic help desks. The 15-minute emergency SLA is a response commitment, not a resolution promise. The distinction matters: any vendor quoting a resolution time for an unseen production fault is guessing.

Yes, and it is the most common deployment we take on. Coverage includes the RabbitMQ Cluster Operator, StatefulSet and persistent volume sizing, network policy for inter-node Erlang distribution, and rolling update strategy that keeps quorum rather than losing members mid-upgrade. On EKS, AKS, GKE, OpenShift or self-managed clusters. The failure modes that matter on Kubernetes are different from bare metal — pod eviction during memory pressure, PVC IOPS starvation and partition detection across node restarts — and those are what the on-call runbook is built around.

Both, and they are separate problems. High availability is quorum queue sizing, node placement across availability zones, and what actually happens to publishers during a partition — the difference between a cluster that survives losing a node and one that stalls. Disaster recovery is cross-region replication, warm standby, and a tested recovery procedure with a real RPO and RTO rather than an assumed one. Support includes reviewing both against your topology, and the review usually finds that the HA design is sound and the DR plan has never been exercised.

Support includes defining what to monitor and reviewing what you already collect; proactive support adds monitoring that AceMQ runs and watches for you. The signals that predict incidents are queue depth trend rather than absolute depth, consumer utilisation, memory and disk alarm headroom, file descriptor and Erlang process limits, and partition detection. Most estates we inherit alert on the broker being down, which is the one failure you find out about anyway. We instrument for the degradations that precede it, using Prometheus and Grafana or whatever you already run.

Yes. A security review covers TLS configuration and cipher selection, authentication and authorisation across vhosts, management UI and API exposure, inter-node Erlang cookie handling, and the plugin surface you have enabled. CVE work is ongoing rather than a one-off: assessment against the versions you actually run, and a patching plan for each advisory that applies. Findings come as a written report with severity and remediation, in a form you can hand to an auditor.

That is the usual case. Onboarding starts with a health check that establishes what you are running (version, topology, queue types, known faults, patch position) so the first incident is not also our first look at the cluster. Most estates are inherited, undocumented, or built by people who have since left, and none of that is a barrier to putting a support contract in place.

Any of four kinds of provider: Broadcom, for the commercial Tanzu RabbitMQ distribution on current series; a hosted platform, for brokers it hosts; an independent consultancy, for architecture and remediation; or an authorized partner such as AceMQ, which supports open-source and commercial RabbitMQ in production, on your infrastructure or in your cloud account, under a 24/7 contract with a 15-minute emergency SLA and direct escalation to the RabbitMQ core team.

Hosted platforms such as CloudAMQP and Amazon MQ support the brokers they host; independent consultancies support current releases on a retainer; AceMQ, an authorized Broadcom partner, supports open-source and commercial RabbitMQ on any infrastructure, under a 24/7 contract with a 15-minute emergency SLA.

Yes. Troubleshooting is the core of it: memory and disk alarms, queues that stop draining, connection churn, partitions, and clusters that will not reform after a restart. We also plan and carry out upgrades, through to the latest RabbitMQ versions, including the feature flag sequencing, the move from mirrored classic queues to quorum queues, and the Erlang version that each release requires. Upgrades are rehearsed against a copy of your definitions first, so the production change is a known quantity. For platform teams that run RabbitMQ as shared messaging infrastructure, we also review best practices for high availability, scalability and tenant isolation.

All of the ones RabbitMQ ships. That means AMQP 0-9-1 and AMQP 1.0, MQTT for device and IoT traffic, STOMP, and the stream protocol, along with the plugins most production estates depend on: management, federation, shovel, Prometheus metrics and the authentication backends for LDAP and OAuth 2. On the application side we work with the maintained client libraries for Java, .NET, Python, Go, Node.js and others, because many incidents that look like broker faults are channel handling, prefetch or reconnection behaviour in the client. Custom or third-party plugins are supported on a best-effort basis, and we will tell you when one is the cause.