Magento message queues: when consumers stop, orders pile up
Not everything Magento does during a purchase happens in that request. Some work goes into a message queue for consumers to process later. When consumers stop, the checkout still works — and the consequences show up afterwards.
What runs in queues
Depending on version and modules: inventory salable-quantity updates, bulk operations, exports, product imports, and integrations for some payment, ERP and marketplace modules. Consumers run either through cron (`consumers_runner`) or as long-running processes under a supervisor. See the message queue documentation.
If cron stops, cron-started consumers stop too — one more reason to watch cron and indexers.
What goes wrong
Salable quantity stops updating, so products oversell or show “out of stock” wrongly — covered in MSI salable quantity. Orders are not sent to the ERP. Bulk price updates never apply, so the cart quotes old prices.
With RabbitMQ, a stopped broker or full disk means messages are not accepted at all, and the code that publishes them may throw errors in the middle of a checkout.
Watching the queues
Alert on queue depth and on messages older than a few minutes, and make sure consumer processes restart after deploys. Check the broker’s health if you use RabbitMQ.
Pair it with an end-to-end check that verifies the cart price and completes a purchase: that catches the customer-visible result of a stuck queue even when the queue metrics are not in place yet.
Check your own store now with the free Magento checkout test: it walks the checkout in a real browser, Luma or Hyvä, and shows the step where it stops.
Orders that stay in Pending Payment are covered in Magento orders stuck in pending payment.
Running consumers: cron or supervisor
By default Magento starts consumers from cron through `consumers_runner`, limited by `cron_consumers_runner` in `app/etc/env.php` (`max_messages`, `single_thread`). That is fine for small stores; busy stores usually run them under supervisor or systemd so they restart on crash and are not killed by the next cron cycle.
List them with `bin/magento queue:consumers:list` and start one by hand with `bin/magento queue:consumers:start <name>` to see its errors. With RabbitMQ, the management UI shows queue depth; with the MySQL queue, look at the `queue_message_status` table.
Signs a consumer is stuck
Bulk actions in the admin that stay "in progress", product price or stock updates that never reach the storefront, and exports that never finish are the usual symptoms. On the checkout side, inventory reservations and async order emails can lag, which shows up as wrong salable quantity or missing confirmations.
Alert on queue depth growing for more than a few minutes, not just on a process being alive. For the order side, also see orders stuck in pending payment and salable quantity in MSI.
Common questions
How do I list Magento queue consumers?
Run bin/magento queue:consumers:list to list them and bin/magento queue:consumers:start <name> to start one.
Who starts Magento consumers?
Cron starts them through consumers_runner unless cron_consumers_runner is disabled in env.php; with RabbitMQ many teams run them under a supervisor instead.
What breaks when consumers stop?
Salable quantity updates, async order placement, exports and other queued work pile up, so stock and orders drift.