Message Broker Production Readiness Checklist: RabbitMQ, Kafka and Redis Quick Check

Answer each question for each broker you run, yes or no, from what you can verify today, not from what the design document says. This page is the cross-broker triage. It does not replace the full checklists, which hold the commands, defaults and pass tests per broker: the Kafka production readiness checklist, the Redis production readiness checklist and the RabbitMQ production readiness checklist.

Each table cell is kept to the one fact that decides the answer, and each command in the last column is a read-only query of the running broker. RabbitMQ rows were checked against rabbitmq.com on 29 October 2026; Kafka rows follow the Apache Kafka 4.4 documentation and Redis rows the redis.io documentation, both as read for AceMQ's full checklists on 28 October 2026. Redis rows apply to Valkey as well.

Yes only if each broker is on a release line its project or a vendor still patches. A broker past that line has no route to the next security fix, so this is the question to answer first.

Yes only if losing one host or one zone leaves a working majority and a copy of the data. Replicas that share a rack, host or zone behave like one replica on the day that domain fails.

Yes only if each broker alerts on the trend toward its limit, not only on the limit itself. All three brokers stop serving some clients when they hit a resource limit, and an alert at that point is an outage report.

Configure each alert with a threshold, a severity and an on-call owner, and put each threshold on a dashboard so the trend is visible before the alert fires. Metrics, dashboards and logs together are the observability the on-call engineer works from. RabbitMQ's HTTP API also exposes health checks, such as /api/health/checks/local-alarms, that a load balancer or monitoring probe can call in addition to the metrics.

Yes only if someone has restored from the backup or failed over to the recovery copy and written down how long it took. A backup that has never been restored is an assumption. It matters most where the broker holds the only copy of the data, as when Redis or Valkey is used as a primary database rather than a cache.

Yes only if no application connects with a default or shared account and traffic that crosses a network you do not control is encrypted. A shared identity makes an incident impossible to trace and a leaked credential impossible to revoke cleanly.

Access control has to hold at every endpoint a client or an operator can reach: the client listener, any management or admin interface, and the links between brokers. Check each one, not only the endpoint the applications use.

Yes only if the next version is named and the route to it is written and tried on a copy. Each broker has one step that blocks a later upgrade when it is skipped, listed below. Each is a dependency: the later step cannot start until the earlier one is done.

The six questions work as a production readiness audit when they run on a schedule, and as a gate before a deployment or an upgrade. A workflow that holds up in practice has five steps.

1. Audit. Answer all 18 cells (six questions for each of three brokers) once a quarter and before any change window. Record the answer, the owner and the date.
2. Give every threshold an owner. A threshold from question 3 is only useful if it pages someone. Name the on-call engineer for each broker and check that the on-call runbook holds the commands from the tables above.
3. Gate the deployment. Before you deploy, upgrade or reconfigure a broker, answer questions 1, 4 and 6 again for it. The change goes ahead only with a restore that has been rehearsed end-to-end and a written upgrade path.
4. Write the rollback before the change. For RabbitMQ, enabling a feature flag cannot be undone and rules out downgrading the nodes, so after that step the way back is a restore, not a rollback of the version.
5. Automate the commands. Automation of the read-only commands from the tables, as a scheduled job that stores the output with its date, means a person reviews what changed instead of collecting the data by hand.

Fix the noes in this order: question 1, then 4, then 2, then the rest. That order is AceMQ's practice, not a documented rule: an unsupported release and an untested restore are the two gaps with no quick recovery once something fails, and a shared failure domain is the next most likely cause of a full outage. For each no, run the matching group in that broker's full checklist.

Most teams can close one or two noes themselves. If the noes cluster on one broker nobody on the team owns, a health check reads that broker's configuration and returns a ranked fix list. AceMQ supports RabbitMQ, Kafka and Redis, and covering several technologies under one contract earns a multi-technology discount. AceMQ has 160+ customers and handles 40+ Sev 1 incidents a year, and we reply to quote requests within 1 hour.