On this page
What it is, in short
The knowledge base is a reference for the problems production RabbitMQ keeps producing: queues that stop draining, nodes that will not rejoin, certificate and access faults, federation and shovel links, Kubernetes operator behaviour, upgrades and version questions. Use it first for a known symptom with a non-destructive check. For production down, raise a P1: a named senior engineer joins a live bridge within 15 minutes, which is a response time, not a resolution time.
It does not replace an engineer for destructive recovery steps or for any case where two plausible explanations call for different actions.
What this page covers, and what it does not
This page describes the content and the use of the knowledge base, not the contract around it. For plans, severity levels, response times and what a support agreement includes, use the support page. For how to compare 24/7 SLAs across providers, use the SLA guide. Access arrangements are part of the support agreement, so ask what your plan includes on the intro call.
The knowledge base is built from the problems our support engineers resolve, rather than from the documentation. That is why its coverage follows what goes wrong in production, which AceMQ has measured in its own ticket data: in 145 RabbitMQ support tickets between 2023 and 2026, no category was larger than 17%, so the next ticket is as likely to be a certificate as a partition.
What is in it: seven areas and the questions they answer
The library covers seven areas. The table shows the type of question each one answers, as typical examples rather than a list of article titles, and the public material that covers the same ground without a contract.
| Area | A typical question | Public starting point |
|---|---|---|
| Cluster and node recovery | A node will not rejoin after an upgrade; how do I recover it without rolling the whole cluster back? | Troubleshooting decision tree; failure patterns guide |
| Queue behaviour | A queue has stopped draining, or will not delete cleanly; what is safe to do? | Troubleshooting decision tree; queue type worksheet |
| Federation and shovel | Links restart when a node joins, a federated queue is duplicated, or a definitions export fails | Federation and shovel runbook |
| Kubernetes and operators | Operator reconciliation, persistent volume handling and security contexts after a change | Kubernetes troubleshooting checklist |
| TLS and authentication | A certificate name does not match behind a load balancer on port 5671 | Security and hardening guide |
| Performance | Throughput drops under load; is it the broker, the clients or the network? | Performance tuning guide; alert rules pack |
| Versions and CVEs | Does this advisory apply to the version and configuration I run? | CVE lookup by version; version support matrix |
How it is used during an incident
Use the knowledge base before and while an engineer is engaged, not instead of one. What the support page promises for a P1 is the sequence below: a page, a named senior engineer on a live bridge within 15 minutes, hands-on isolation, and a written root-cause analysis after every P1. The knowledge base sits in the first two steps for known symptoms and is not part of the fix for unknown ones.
- Match the symptom. Search for what you see: the alarm, the queue name, the log line. A non-destructive check or a known cause can resolve a common case without a ticket.
- Decide whether it is a P1. If production is down, raise the P1 straight away. Reading the knowledge base while you wait is fine, but do not delay the page to finish reading.
- Hand the engineer the context. The environment one-sheet and what you tried so far shorten the first fifteen minutes.
- After the incident, the written root-cause analysis states the root cause, the fix applied and the prevention steps.
| Situation | Start with | Why |
|---|---|---|
| A known symptom with a non-destructive check, such as a memory alarm approaching or consumers below the expected count | The knowledge base | The cause and the check are usually the same as a previous case |
| Production is down | A P1 ticket, then the knowledge base while the engineer joins | The 15-minute response is a response time, so the page should not wait |
| The recovery step is destructive, such as removing a node from the cluster or deleting queues | An engineer | These are the calls worth waking someone for |
| Two plausible explanations lead to different actions | An engineer | A wrong guess costs more than the time to ask |
| Whether a security advisory applies to your configuration | The CVE lookup, then your engineer for the audit answer | The answer has to be specific to the version and settings you run |
Asking it in plain language
The knowledge base can be queried in plain language, so an engineer in the middle of an incident can ask the question they would have put in a ticket. That is a convenience on top of the library, and it is set up to hand off to a ticket rather than guess: where there is no answer, or the matter is active, security-related or commercial, the route is a ticket, and the ticket's response commitment still applies. Ask your account contact how it is offered under your plan.
What it does not replace
It does not replace an engineer wherever the recovery step is destructive or where two plausible explanations lead to different actions. Those are the calls worth waking someone for, and the knowledge base is meant to point you at a ticket in those cases rather than guess.
It also does not replace the proactive work that runs between incidents: quarterly health checks, version and CVE tracking, and upgrade planning, which are described on the support page.
Free equivalents you can use today
A good deal of the same ground is public. The troubleshooting decision tree, the production readiness checklist, the upgrade runbook and the CVE lookup cover the most common cases without a contract, and the knowledge base goes further into the long tail of specific estates. Start with those if you are not yet a support customer.
Open source, community support and commercial support
RabbitMQ is open source: the server is released under the Mozilla Public License 2.0, and its code and release notes are on GitHub. That is a separate question from support. Community support is help from the RabbitMQ community through channels such as GitHub Discussions and Discord, with no response-time commitment, and each release series gets free security updates and bug fixes until its community support timeline ends. Commercial support adds help from RabbitMQ experts during that timeline and extended support after it. The project's release information page publishes both sets of dates and points to the Broadcom support portal for the authoritative commercial lifecycle, because it describes the commercial end dates as indicative.
Commercial RabbitMQ is sold by Broadcom as VMware Tanzu RabbitMQ, and AceMQ is a Broadcom partner, so licensing and support can be bought together. The licensing page explains the options.
Questions about how RabbitMQ works, such as protocols (AMQP 0-9-1 and AMQP 1.0, which has been native since 4.0, plus MQTT and STOMP through plugins), client libraries and typical use cases, are well answered by rabbitmq.com. The knowledge base is aimed at the other kind of question: what to do when a production deployment misbehaves. To check which versions still receive fixes and which are the latest RabbitMQ versions, use the version support matrix.
| Source | What it gives you | Limit |
|---|---|---|
| Open-source docs and GitHub | Documentation, release notes and the code, under the Mozilla Public License 2.0 | Describes how RabbitMQ works, and does not know your estate |
| Community support | Free security updates and bug fixes during the community support timeline, and help from other users | No response-time commitment, and it ends with the series |
| Commercial support | Help from RabbitMQ experts during the community timeline, plus extended support after it | Scope and response times are set in the agreement |
| AceMQ knowledge base | Resolutions and runbooks from the support desk, organised by the problems production RabbitMQ produces | What it covers is on this page; plans, terms and response times are on the support page |
Frequently asked questions
What is the AceMQ RabbitMQ knowledge base?
A library of RabbitMQ resolutions and runbooks organised by the problems the AceMQ support desk sees: cluster and node recovery, queue behaviour, federation and shovel, Kubernetes and operators, TLS and authentication, performance, and versions and CVEs.
Does the knowledge base replace a support ticket?
No. It shortens the common cases and it is set up to hand off to a ticket when there is no answer or the matter is active, security-related or commercial. For production down, raise a P1: a named senior engineer joins a live bridge within 15 minutes.
What does a 15-minute P1 response mean?
It is a response time, not a resolution time. Within 15 minutes of a P1 a named senior engineer joins a live bridge. Nobody can honestly promise a resolution time for a production fault they have not yet seen.
Who can use the knowledge base?
It is part of how AceMQ supports its RabbitMQ customers. What your plan includes is set in the support agreement, so ask on the intro call. We reply to support enquiries within 1 hour.
What is the difference between community support and commercial RabbitMQ support?
Community support is free help from the RabbitMQ community, with security updates and bug fixes until each series reaches the end of its community support timeline, and no response-time commitment. Commercial support adds help from RabbitMQ experts during that timeline and extended support afterwards, under an agreement with defined response times.
Is there a free equivalent?
Partly. The troubleshooting decision tree, production readiness checklist, upgrade runbook and CVE lookup on this site cover the most common cases without a contract.