24/7 RabbitMQ Support for Enterprises

Yes, but only the current release series receives community support. Once a series reaches end of commercial support dates it stops getting security fixes from the project, which is why teams running older brokers either upgrade or take extended commercial support that backports CVE patches to the version they are on. AceMQ maintains a support lifecycle for versions the community has already dropped. What extended support covers, series by series →

Yes, and this is the gap most teams fall into. Commercial RabbitMQ licensing reaches back to 3.13.x; AceMQ's support window reaches back to 3.8.x. If you run 3.8 through 3.12 you are outside the licensing window entirely but still inside ours, so you get CVE patches backported to the build you are actually running rather than an ultimatum to upgrade this quarter. That covers frozen change windows, certified applications, air-gapped estates, and vendors who have not qualified a newer release. The full coverage terms, including how backports are scheduled, are on the extended LTS support page at /rabbitmq/extended-lts-support/. Extended support for versions the community has dropped →

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 patches for older versions, 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, security patching including backports to versions the project no longer maintains, 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, back to version 3.8.x. 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 four axes. Version coverage: current series only, or older versions with backported patches. 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 four of the latter: named engineer, both distributions, versions back to 3.8.x, 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; on managed services we run the monitoring ourselves. 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 patches backported to your build where the series is past its community window — RabbitMQ 3.8.x onward, which is further back than commercial licensing reaches. 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, back to version 3.8.x, under a 24/7 contract with a 15-minute emergency SLA and direct escalation to the RabbitMQ core team. If you would rather we ran it: managed RabbitMQ services →

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 back to 3.8.x, including the series Broadcom's commercial window no longer reaches, with CVE fixes backported to the build you actually run. Coverage for the 3.8 to 3.12 series Broadcom no longer patches →

The one whose contract matches how your estate fails. For production, check five things before the name: whether open-source builds are covered or only the commercial distribution; how far back the version window reaches; whether the first responder is a senior engineer or a triage tier; the contracted response time for an emergency; and whether the provider can escalate into the RabbitMQ core team. AceMQ meets all five, supports 130+ enterprise clients in 26+ countries, and is the only Broadcom-authorized Tanzu RabbitMQ managed services provider. Production support engagements we have run →

Management, as opposed to support, means someone else holds the pager. Hosted platforms manage brokers inside their own accounts; AceMQ manages RabbitMQ on your infrastructure or hosts it on ours, covering monitoring, patching, upgrades, capacity and 24/7 on-call with a named senior engineer, and hands back a documented platform if you ever want to take it in-house. What managed RabbitMQ from AceMQ covers →