RabbitMQ Help: Emergency Support for Split Brain and Full Disks

Save the evidence before you restart anything: run rabbitmqctl cluster_status on every node, copy the logs, and note which side your applications are connected to. Then decide which partition holds the state you want to keep, because that decides which messages survive. If you cannot make that call confidently, phone us on +1 305-204-2607 and we will work it with your engineers. Under a support contract we are on the incident within 15 minutes.

Run rabbitmq-diagnostics alarms to confirm a disk alarm is active. RabbitMQ blocks publishers while it is set, which is why producers hang with no error from the broker. Find out what is using the volume before you act. A growing backlog means consumers have stopped, which needs fixing or the disk fills again. Do not delete files from the data directory by hand. Extend the volume or free space safely, and let the alarm clear.

Support is an ongoing contract with an SLA for incidents as they happen. Troubleshooting is a scoped engagement aimed at one persistent or recurring problem you have not been able to resolve — typically something that has been open for weeks and survived several attempted fixes. Many customers start with a troubleshooting engagement to clear a specific issue, then move onto a support contract to keep it from recurring.

For an active production incident, we can have a senior engineer engaged within 15 minutes under a support contract, or same-day for a new emergency engagement. For a persistent non-urgent problem, engagements typically start within a few business days. Tell us the severity when you contact us and we will be direct about what we can commit to.

At minimum, read access to the management API or metrics, broker logs, and configuration. Interactive access to a live session with your engineers is significantly faster than an asynchronous log exchange. We work regularly in restricted and air-gapped environments where direct access is impossible, and can guide your team through the diagnostic steps instead — it takes longer, but it works.

That happens often, and we will tell you. RabbitMQ symptoms frequently originate in storage latency, network policy, JVM or client library behavior, Kubernetes scheduling, or a security agent interfering with the Erlang runtime. We diagnose across the full stack because that is where the cause usually lives, and we would rather hand you an accurate answer about your storage layer than a plausible one about your broker.

Both, and the fix is included. We implement remediation with your team rather than delivering a report and leaving. Where the correct fix belongs in your application code, we specify exactly what needs to change and why, and review it with your developers — we just will not merge to your application repositories on your behalf.

Yes. Many regulated environments cannot upgrade on the community's timeline, and that is a normal enterprise constraint rather than a disqualifier. We troubleshoot RabbitMQ from 3.8.x to 4.x, apply workarounds where upstream fixes are not available for your version, and will tell you honestly when a specific problem genuinely cannot be resolved without upgrading.

A written root-cause analysis, the applied and validated fix with before-and-after metrics, monitoring and alert rules that would have caught the issue earlier, and a diagnostic runbook written for your specific topology. The runbook matters most: it means the next incident of this class gets handled consistently, whoever is on call.