Magento 2 Cron Not Running? Diagnose Where Background Work Stops

“Magento cron is running.”

That sounds reassuring—until order emails are delayed, product updates fall behind, or scheduled tasks stop progressing.

The problem is that “running” can describe several different things.

A server can launch Magento cron without the expected jobs completing. A job can complete without producing the business result you expected.

Here is a practical way to separate those layers before changing anything.

1. Is the server launching Magento cron?

Start with the mechanism responsible for invoking Magento.

For a self-managed installation, inspect the scheduler configuration for the account that owns and runs the application.

Check:

• Does the entry reference the current Magento installation?
• Does it use the intended PHP executable?
• Can that account access the application and write required files?
• Is there evidence of recent execution?
• Did a deployment change the release path or runtime?

A configured entry shows intent. Recent execution evidence shows whether it actually runs.

For Adobe Commerce Cloud, use the platform’s cron configuration and logs rather than assuming a conventional user crontab controls the application.

2. Is Magento scheduling the expected work?

Once invocation is established, inspect whether Magento is creating schedules for the jobs you expect.

Focus on the affected job and a recent time window.

An empty result does not automatically prove that all cron is broken. Possible explanations include:

• The job is disabled or no longer registered.
• You are checking the wrong database or environment.
• The job belongs to a different cron group.
• Your query window does not include its schedule.
• Schedule generation is not progressing.

Confirm the job code and configuration before drawing a conclusion.

3. Are scheduled jobs executing?

Interpret job statuses in context.

Status	What it tells you	What to investigate
pending	Work is scheduled and has not started	Whether it is due and whether execution progresses
running	Execution has started	Duration, process activity and possible blocking
success	Magento recorded successful completion	Whether the expected business outcome followed
missed	The job missed its execution window	Scheduler delays, capacity and cron configuration
error	Execution reported a failure	The recorded message and related application logs

One pending job is not necessarily a backlog. One running job is not necessarily stuck.

Compare observations over time and consider the job’s expected frequency and duration.

4. Did the business result happen?

This is the step that status-only monitoring can miss.

For an email problem, distinguish:

1. The relevant job executing.
2. Magento handing the message to the configured mail transport.
3. The receiving mail system accepting it.
4. The message reaching the intended inbox.

A successful cron status does not prove all four.

Similarly, successful background execution does not by itself prove that the storefront now displays the expected stock, price or search result.

Verify the symptom that triggered the investigation.

An illustrative troubleshooting example

Suppose order emails are delayed.

You confirm that the server launches Magento cron and that recent schedules exist.

The affected job repeatedly reports an error. Its message points to a mail transport connection failure.

In this example, reinstalling cron would not address the underlying problem. The next investigation belongs in mail connectivity and transport configuration.

After correcting that issue:

• Confirm a new execution completes.
• Verify a controlled email reaches its destination.
• Check whether previously queued work progresses.
• Watch for the same error to recur.

This is an illustrative scenario, not a documented customer incident.

Collect evidence before applying a fix

Before resetting anything, record:

• Environment and Magento version.
• Relevant job code and cron group.
• Timestamps and timezone.
• Recent status transitions.
• Error messages.
• Related process or service observations.
• The customer-facing symptom.

Avoid sharing credentials, customer details or unredacted logs in public discussions.

This evidence makes a developer handoff more useful than “cron seems broken.”

Watch for a monitoring blind spot

If a health monitor depends entirely on Magento cron, it may stop checking when cron stops.

That creates a gap: the process responsible for detecting failure depends on the process that failed.

An independent heartbeat can help detect missing execution. It should complement job-level and business-outcome checks, because a heartbeat alone does not prove every job succeeded.

Verify recovery over time

A single successful manual run is useful evidence, but scheduled recovery requires more.

Confirm that:

1. Normal scheduled invocation resumes.
2. Expected jobs are scheduled and executed.
3. Backlogs progress where applicable.
4. The original business symptom is resolved.
5. Failures do not immediately return.

Follow the complete diagnostic workflow

The full Buildmerce guide includes diagnostic commands, bounded SQL queries, job-status interpretation, recovery checks and an interactive investigation selector.

Read Magento 2 Cron Not Running: Diagnose Where Background Work Stops.

For the wider operational checklist, see our Magento 2 Health Check guide.

When background work stops progressing, which layer do you investigate first: invocation, scheduling, execution or the business outcome?