What Breaks in Production RabbitMQ: 145 Support Tickets, 2023 to 2026

Each of the 145 tickets was read and placed in one category by its subject. No category dominates. The largest, queues, consumers and message flow, is 17% of the total, and the top five categories sit within four points of each other. Anyone planning support cover for RabbitMQ should read that as a warning against specialising the on-call rota: the next ticket is about as likely to be a certificate as a partition.

Add the client-side categories together, message flow plus load balancers, connections and client settings, and they account for 33 tickets (23%). Those are problems where the broker was usually doing what it was told. The fix was in consumer acknowledgement, prefetch, connection handling or the proxy in front of the cluster.

The leading category changed every year. In 2023 it was TLS, certificates and access, as new estates were stood up and secured. In 2024 it moved to message flow. In 2025 upgrades led, as the 3.x series left community support, with federation close behind. In 2026 message flow leads again, and Kubernetes and operator tickets appear almost from nowhere: 10 of the 12 in that category were opened in 2026.

Federation follows the same curve. There was 1 federation or shovel ticket in 2023, 0 in 2024, 5 in 2025 and 6 so far in 2026. Multi-site RabbitMQ is no longer unusual, and its failure modes (links restarting when a node joins, duplicated federated queues, definitions that will not export) are not ones a single-cluster team has seen before.

Volume roughly doubled in 2026. That reflects more estates under contract, not brokers becoming less reliable, so read the shares rather than the counts.

Windows is more present in production RabbitMQ than most guides assume. 27 of the 145 tickets (19%) name Windows Server, IIS or a .NET client, against 16 (11%) that name Kubernetes, an operator or Helm. Windows tickets cluster around service start failures, patching windows, antivirus exclusions and upgrades; Kubernetes tickets around operator reconciliation, persistent volume handling, security contexts and what happens to quorum during a node upgrade.

30 tickets name a release series from 3.12 onward. The 3.12 and 3.13 series are named most, in 14 and 14 tickets, which is what you would expect from the installed base: both are past community support, and a large share of upgrade tickets are about leaving them. Quorum queues are mentioned in 13 tickets, federation in 12, and classic mirrored queues or HA policies in 9, the last group being estates that have not yet finished the move mirroring requires before RabbitMQ 4.

57 tickets (39%) use the language of service impact in the customer's own words: down, outage, crashed, failed, not working, data loss. 30 name a production environment. The ticket system records every ticket at the same priority, so this is the only severity signal available and it should be read as indicative.

The source is the ticket log of AceMQ's RabbitMQ support desk from 9 February 2023 to 16 September 2026: 168 tickets. 23 were removed before analysis: 10 tests or cancelled tickets, 3 duplicates or re-opens of an earlier ticket, 3 about Redis rather than RabbitMQ, and 7 administrative. The remaining 145 were each assigned one category from the ticket subject and description by one reviewer; a ticket that touched two areas went to the one the customer led with. Platform, version and impact figures come from keyword matching on the ticket text, so they undercount anything the customer did not write down.

The limits are the obvious ones. This is one provider's customers, weighted toward regulated and enterprise estates that buy support. Ticket counts grow with the number of estates under contract. No customer, host name or ticket text is published, and the released dataset contains only a sequence number, the quarter, the category and the flags described above.