Magento cron problems start with a business symptom
Magento cron runs work that customers may never see directly but depend on throughout the day. When scheduled work stops, the first complaint might be an old price, a delayed message, a catalogue update that never appears or an export that has fallen behind. These symptoms do not prove that cron is the cause. They tell us which business process to trace and which expected completion time to compare with the actual result.
At Midoriweb, our starting point is the affected workflow. We ask what should have happened, when it last worked and whether the failure affects everything or one particular job. A store with one failing integration task needs a different intervention from a server that has stopped launching Magento altogether. This distinction avoids unnecessary restarts and keeps the investigation tied to an observable outcome.
If customers cannot place orders, describe that impact in an emergency support request. For slower background processing without an immediate trading outage, Magento support provides a route to a properly scoped investigation.
Separate the scheduler, Magento jobs and business completion
There are three useful checkpoints. First, does the operating system launch the intended Magento command? Second, does Magento schedule and execute the relevant job? Third, does that job complete the business action successfully? Passing one checkpoint does not establish the next. A scheduler entry can exist while its command fails, and a job can complete without a downstream system accepting the intended change.
Adobe documents cron as a requirement for scheduled Commerce work. Its cron configuration guide is the reference for the installed product. Exact job groups and extension behaviour vary, so an old command copied from another server is not a reliable specification for your current installation.
For one affected job, record the expected schedule, last successful execution, recent error and business result. Keep these observations in a single timeline. That makes it possible to distinguish a new failure from a backlog that has been accumulating quietly for days.
Check the execution environment after a deployment or hosting change
The PHP used by the web server may differ from the PHP used by scheduled commands. A site can therefore load normally while background work fails because the command uses an unsuitable binary, different configuration or a different set of extensions. The working directory and operating-system account also matter. A command that succeeds in an administrator’s interactive shell may not behave the same way under the scheduler.
We compare the configured command with the actual deployment path, intended file owner and supported runtime. Recent migrations, changed release directories, permission adjustments and hosting-panel updates are useful clues. We do not solve an ownership mismatch by making application directories writable by everyone. The goal is to restore the intended execution context with the smallest justified change.
Capture the real error before changing anything. An inaccessible file, missing extension and exhausted memory limit can all look like a stopped job to the merchant, but require different fixes.
Read job history as a pattern rather than a single status
A single running or pending record is not automatically a fault. Look at elapsed time, expected frequency and whether subsequent work is progressing. Compare the affected period with a normal period. A task that usually completes quickly but now overlaps its next scheduled run deserves attention even if some executions still succeed.
Group failures by job code and time. Many unrelated jobs failing together can point towards a shared dependency. One integration repeatedly failing while other tasks complete is a reason to inspect that integration’s inputs, remote response and retry behaviour. Record whether failures repeat at the same point or move between different records.
Avoid deleting the job history to make the dashboard look clean. That can remove evidence without repairing the cause. Retention and housekeeping should be handled deliberately after the incident is understood, not used as a substitute for diagnosis.
Find why the backlog grows
Background processing can be active yet unable to keep pace. Compare incoming work with completed work over the same period. Large catalogue imports, expensive custom jobs, slow remote APIs and shared database contention can extend runtimes. A higher execution frequency will not necessarily help if jobs compete for the same limited resource.
Map the busiest tasks against storefront activity. If an import and full reindex overlap a sales peak, investigate the combined workload rather than treating each job in isolation. Our stuck indexer guide covers index-specific evidence. Queue consumers have their own processing model; do not assume that every queued message is processed by the same cron mechanism.
A useful recovery plan states how much work is waiting, which items are time-sensitive and what capacity is available to process them safely. This is more actionable than simply reporting that cron is running again.
Recover without duplicating business actions
Before restarting or replaying work, establish whether earlier executions partly succeeded. An export may have reached an ERP even when Magento recorded a timeout. An email job may have handed a message to the mail service before failing later. Repeating the whole batch without checking these boundaries can create duplicates or contradictory updates.
Midoriweb would identify the smallest safe retry unit and verify the receiving system where relevant. For a catalogue task, that may be a limited set of affected products. For an integration, it may be one documented external reference. Recovery should have a stop condition if errors increase or live customer response deteriorates.
Do not reset a running task merely because its status looks old. Confirm whether the process is still doing useful work, waiting on a dependency or genuinely abandoned. The appropriate intervention depends on that evidence and the installed extension’s behaviour.
Verify both technical health and the merchant’s workflow
A successful manual execution is a useful test, but the scheduled path must work independently afterwards. Observe more than one expected cycle and confirm that the backlog is reducing rather than being replaced by fresh failures. Check the original business symptom as well: the price should update, the message should arrive or the receiving system should contain the expected record.
Monitoring should distinguish failure, delay and missing execution. An alert that fires only on a logged exception may miss a command that never started. Agree which jobs are critical, what delay is acceptable and who receives the alert. Include enough context to investigate without embedding customer details or credentials in notifications.
For an investigation brief, provide the affected process, approximate first failure, last known success, recent changes and the relevant job name if known. We can then scope access and technical checks around the actual problem rather than requesting broad access without a purpose.
Questions about Magento cron failures
Can the storefront work while cron is broken?
Yes. Interactive requests and scheduled work follow different execution paths. Some symptoms become visible only when background tasks fall behind, which is why the actual job result matters alongside homepage availability.
Should I run all cron jobs manually?
Not as a first response. Establish what is failing and whether work is already running. A broad manual run may overlap existing tasks or repeat actions that have partly completed.
Does changing hosting fix cron problems?
Only if the relevant hosting constraint is established and the new environment addresses it. Configuration, permissions, extension errors and downstream failures can follow the store to another server.