Magento Automated Emails: Why Cron Is Usually the Cause

Why do Magento automated emails stop sending?

Magento automated emails almost always stop for one of a small number of reasons, and the most common one by a wide margin isn’t a broken template or a bad SMTP password. It’s cron: order confirmations, shipment notices, invoices and password resets are queued rather than sent the instant they’re triggered, and that queue only clears when Magento’s scheduled tasks actually run. When the underlying schedule stops, the storefront keeps behaving normally, the order still shows as placed, and nothing in the checkout flow tells the shopper or the merchant that a message never left the building. This article ranks the causes in the order we actually see them, not by theoretical severity, because the fix for the rare cause wastes an afternoon if you reach for it before ruling out the common one.

That gap matters specifically for stores on $3M-plus revenue running Magento Open Source or Adobe Commerce with more than a handful of daily orders, where a silent two-day gap in shipment notices generates a support queue backlog before anyone traces it to a schedule that quietly stopped weeks earlier. If you’re running a single low-volume store view with infrequent orders, a manual check after each deploy is a reasonable substitute for the monitoring this article describes; at volume, it isn’t.

How Magento actually sends an automated email

Magento’s transactional email system separates three things that are easy to conflate when something goes wrong: the template, the trigger, and the delivery mechanism. The template is the content, assigned per store view or falling back to a default. The trigger is the order-lifecycle or account event — an order placed, a shipment created, a password reset requested — that decides when a template gets used. The delivery mechanism is what actually gets a generated email out to a mail transport, and for most transactional email that mechanism is a queue rather than a direct, synchronous send.

The queue exists so that generating and sending an email doesn’t hold up the request that triggered it. A shopper completing checkout shouldn’t wait on an SMTP handshake before seeing an order confirmation page, so Magento generates the email, drops it into a queue, and a separate scheduled process picks queued messages up and sends them. That separation is the right design for a storefront under load. It’s also the exact point where automated email quietly breaks, because the queue depends entirely on something outside the checkout flow continuing to run on schedule, and nothing in the checkout flow checks that it did.

Multi-store scope adds a second dimension that’s easy to miss when you’re troubleshooting a single symptom. Template assignment, sender identity — the name and address an email appears to come from — and locale are all configurable per store view or per website, not globally. A fix applied at the default scope doesn’t automatically propagate to a specific store view that has its own override sitting on top of it, and a merchant who edits “the” order confirmation template in the admin can still leave three store views sending an older version untouched. Cron and the queue it processes, by contrast, generally operate at the instance level: one schedule serves every store view running on that installation, which means a cron failure takes down email for every store at once even though template problems tend to be scoped to just one.

How do marketing emails differ from transactional emails here?

Transactional email and marketing email share Magento’s server, but they don’t share one mechanism, and conflating them is a common reason troubleshooting goes down the wrong path. Transactional email — order confirmation, invoice, shipment, password reset — runs through the template and queue system: generated on an order or account event, held in the queue, then sent once cron processes it. Marketing email, meaning a newsletter or a campaign sent to a subscriber list, runs through a separate subscription mechanism: a shopper opts in, that subscription state is stored against their account or a standalone subscriber record, and the actual send is either handled by Magento’s own built-in newsletter tools or, on a large share of stores at this revenue range, handed off entirely to a connected third-party email service provider through an integration extension.

That split matters for troubleshooting because a cron failure doesn’t necessarily hit both channels the same way. If marketing email is fully delegated to a third-party ESP that pulls subscriber and order data through its own scheduled sync or a real-time webhook, a Magento-side cron outage can leave transactional email frozen while campaign sends continue landing, because the ESP’s own infrastructure, not Magento’s queue, is doing the sending. The reverse is just as possible: if the ESP integration itself depends on a Magento-side export job that runs under the same cron schedule that just stopped, campaign sends can silently fall behind on fresh subscriber and order data while the ESP keeps sending against an increasingly stale list, which looks like a data problem rather than a scheduling one until you trace it back.

Multi-store scope compounds this. A newsletter subscription list, and the sender identity a campaign appears to come from, are typically configured per store view just as transactional templates are, so a merchant troubleshooting “email is broken” on one store view can find transactional mail affected instance-wide by a cron outage while a separate marketing send, delegated to an ESP with its own credentials for that store view, keeps working normally. Treat every automated-email symptom report as scoped to a specific channel and a specific store view until you’ve confirmed otherwise, rather than assuming a single fix covers both.

The ranked causes of automated email failure

This order is our own, built from the pattern we see across Magento and Adobe Commerce stores, not a severity ranking or a vendor’s list. It’s ordered by how often each cause turns out to be the actual reason mail stopped, most common first.

1. Cron stopped running at the operating-system level

Cron stopping at the OS level is the most common cause by a clear margin, and it’s almost never caused by anything inside Magento’s own configuration. Magento’s scheduled tasks depend on an operating-system-level scheduler calling Magento’s own cron command at a set interval, and that OS-level entry lives outside Magento’s admin entirely — in server configuration that a hosting migration, a server rebuild, or a PHP version upgrade can silently drop or misdirect. A migration that moves the application to a new server without carrying the scheduler entry across is the single most common version of this failure we see. A PHP version upgrade that leaves the scheduler pointing at a binary path that no longer exists is the second most common. Both produce the identical symptom: Magento keeps generating and queuing emails exactly as designed, and nothing ever processes the queue, because the process that’s supposed to call Magento’s cron command on schedule simply isn’t running anymore.

The fix is to confirm, at the server level, that the scheduler is actually configured and executing, not just that it was configured correctly at some point in the past. Check Magento’s own cron run history for genuinely recent activity, not just a config screen showing a schedule that looks correct on paper, and consult Adobe Commerce’s current documentation for the specific steps for your hosting environment, since the exact setup differs between a self-managed server and a managed Adobe Commerce Cloud environment.

2. The specific cron group that processes the email queue is disabled or misconfigured

Magento organises scheduled tasks into separate groups rather than one single job, and it’s possible for cron to be running correctly overall while the specific group responsible for queue processing is disabled, misconfigured, or configured with a schedule so infrequent that it looks broken even though it’s technically working. This tends to follow a deliberate change: someone disabled a cron group to troubleshoot an unrelated performance issue, or to stop a resource-heavy indexing job during a busy sale period, and either forgot to re-enable it afterward or didn’t realise the same group also handled something unrelated.

Confirm which cron group handles queue processing in your specific version before touching any group configuration, since this has changed between releases and isn’t something to assume from an older setup. Adobe Commerce’s current cron documentation is the source to check rather than carrying forward a setting from a previous version or a different store’s configuration.

3. The mail transport is rejecting or silently dropping messages

Even with cron running and the queue processing correctly, mail still has to leave the server through an SMTP connection or a transactional email service, and that connection can fail in ways Magento’s own interface won’t surface clearly. A third-party SMTP extension’s API credentials can expire without an obvious in-admin warning. A hosting provider can start blocking outbound mail on a port that used to work, often after a server move or a shared-hosting policy change aimed at reducing spam from the platform generally. Whatever the specific cause, the queue often reports the message as sent from Magento’s point of view, because handing a message to the mail transport layer is what Magento’s own success status tracks — what happens to it after that handoff is a separate system’s problem.

Check the mail transport’s own logs, not just Magento’s queue status, when troubleshooting this specifically. If you’re using a third-party transactional email extension, its own dashboard usually shows accepted, bounced and rejected counts separately from anything visible in Magento’s admin.

4. A template is assigned at the wrong scope and fails silently

A custom template edited or reassigned at the default scope doesn’t reach a store view that has its own override configured beneath it, so a fix that looks complete in the admin can leave one specific store view still sending an old, broken, or entirely wrong template. Separately, a custom template that references a variable no longer supplied the same way — often after an extension update or a platform upgrade changes what data is passed to the template — can fail to render correctly or drop content without throwing an error a merchant would notice from the storefront side.

Re-check template assignment per store view specifically after any change intended to be global, and re-test every customised template, not just the ones you edited, after any extension or platform upgrade. A template problem is scoped to whichever store view it’s assigned to, which is the detail that makes it look like an isolated, confusing bug rather than the systemic issue that cron failures produce.

5. A stuck job is blocking the rest of the queue behind it

Queue processing generally works through items in order, and a single message that triggers an unhandled error during processing can, depending on configuration, leave the queue stalled behind it rather than skipping past and continuing with everything queued after it. This is harder to diagnose than an outright cron failure because it looks similar from the outside — mail stops moving — but cron’s own run history will show jobs executing normally rather than not running at all, which is the detail that tells you to look at the queue’s contents specifically rather than the scheduler.

If cron’s run history looks healthy but mail still isn’t moving, check the queue itself for a message stuck in a failed or retrying state rather than assuming the schedule is the problem a second time. Consult Adobe Commerce’s current documentation on queue and message-queue configuration for how your specific version surfaces and clears a stuck entry, since the retry and dead-letter behaviour has evolved across releases and isn’t safe to assume from memory.

6. Email sending was disabled in a specific store’s configuration during testing

It’s common practice to disable transactional email in a staging or newly launched store view to avoid sending test orders to real customers, and it’s just as common for that setting to survive the cut-over to production untouched, particularly on a new store view added to an existing multi-store instance. The result looks exactly like a cron failure from the storefront side — orders place normally, nothing arrives — but cron’s run history shows everything working, because this cause sits entirely inside configuration rather than the scheduling layer.

Check store-level email configuration specifically whenever a new store view has just gone live and its automated email hasn’t been confirmed with a real order, before assuming the problem is systemic. This is the cause most likely to be scoped to exactly one store view while every other store view on the same instance sends normally.

7. Sender domain authentication has drifted for a newer store view

A store view launched with a different from-address than the one already authorised on your sending domain — through SPF, DKIM or an equivalent authentication record — can have every email accepted internally by Magento as successfully sent, while receiving mail servers quietly drop or spam-folder the message because the sending identity doesn’t match what’s authorised for that domain. This is the cause most likely to be mistaken for a cron problem, because Magento’s own status genuinely does say “sent,” and the failure happens entirely downstream, at the receiving mail server, where nothing in Magento’s admin can see it.

Confirm that every sender identity in use across every store view is authorised on the sending domain’s authentication records whenever a new store view or a new from-address goes into production, and check actual delivery at the receiving end — a real inbox, not just an admin log — rather than trusting Magento’s own success status as proof of delivery.

How to verify the fix actually worked

Testing with an admin “send test email” button proves the mail transport can accept a message. It does not prove the queue is being processed, because that kind of test typically bypasses the queue and sends synchronously. The only test that checks the part that’s usually broken is a real, end-to-end one: place an actual order in a test or low-value SKU, and watch it move through confirmation, and if applicable invoice and shipment, into a real inbox that matches the sending domain’s actual authentication setup, not a personal address on an unrelated domain.

Check cron’s run history over a full scheduling cycle, not a single snapshot, since a schedule that ran once recently but has a gap immediately before or after it can look healthy on a quick glance and still be failing intermittently. If you’ve just fixed an OS-level scheduler issue, confirm it stays running across at least one full day rather than declaring it fixed the moment the next job completes. And treat “the order confirmation arrived” as one data point, not full confirmation: shipment and invoice emails fire on separate later triggers, so a fixed order-confirmation send doesn’t guarantee the shipment email later in the same order’s lifecycle will follow it through cleanly, particularly if the underlying cause was a stuck queue item rather than a scheduler outage.

Automated email failure of this kind is fundamentally a monitoring gap: the storefront never tells anyone that a queue stopped moving, and by the time a customer complains about a missing shipment notice, the gap can already be days old. That’s an AI agents and automation problem before it’s an email problem — a monitoring agent watching cron run history, queue depth and delivery status can flag a stall within hours instead of waiting for a support ticket to surface it days later. Pointerflow’s AI agents service is built around exactly that kind of standing check: not replacing a human decision, but catching the operational failure a human would otherwise only find after the damage compounds.