Magento 2 cron and the message queue: async done right

Magento 2 is not a request/response app alone — much of the real work is asynchronous. Understanding cron and the message queue is what keeps your store responsive under load.

Cron is mandatory

bin/magento cron:install sets up a single entry that dispatches all cron groups on a schedule. Miss it and indexers stall, emails never send, and queues back up. Verify cron_schedule rows are being created.

Cron groups

Work is split into groups (default, index, catalog, etc.). Each runs on its own cadence so a slow job doesn't block others. Don't collapse them into one giant task.

The message queue

Long or external operations — payment callbacks, exports, bulk actions — go through a queue (MySQL-backed by default, RabbitMQ for scale). A consumer (queue:consumers:start) processes them off the request path. This is why a checkout doesn't wait on a third-party API.

Indexers belong async

As covered in the performance post, run indexers on schedule or via the queue, never "on save" for big catalogs. The cron drives that cadence.

Debugging async work

Failures hide in cron_schedule (status, error) and the queue (queue:failed:show for MySQL). Reproduce against a real stack — Govard brings up the same MySQL/Redis topology locally so cron and consumers behave like production.

Where this fits

Async processing is the backbone under the performance best practices and the audit checklist. Get it wrong and every "optimization" above is undone by a stalled indexer.

Next in this series: Build a real Magento 2 module end-to-end — /blog/magento2-custom-module