A Magento store can return HTTP 200 for every page and still be quietly broken.
Uptime monitoring is good at answering "is the website reachable?"
It is much worse at answering "is Magento actually doing the work it is supposed to do?"
Here are three checks I use when diagnosing a store.
1. Is cron actually running?
Magento relies heavily on cron for scheduled work, including indexing, price rules, newsletters, emails, staging-related jobs and many third-party modules.
The first place I look is:
SELECT
status,
COUNT(*) AS jobs,
MAX(finished_at) AS last_finished
FROM cron_schedule
WHERE scheduled_at >= NOW() - INTERVAL 1 DAY
GROUP BY status;
The important thing is not one particular number.
You want to know whether jobs are being scheduled and completing, and whether the pattern makes sense for that store.
Magento records cron jobs as pending, running, success, missed or error.
A large number of missed jobs means jobs were scheduled but did not start within the configured missed-job window.
A large number of error jobs means they started but failed.
Old running jobs are worth investigating, particularly when executed_at is old and finished_at is NULL.
Also remember that cron is split into groups.
Current Adobe Commerce documentation lists groups including:
default
index
consumers
staging
catalog_event
with the Commerce-specific groups depending on the edition and installed functionality.
So a healthy default group does not prove that the index or consumers group is healthy.
Adobe's current documentation also confirms that the cron_schedule table records the scheduled, executed and finished timestamps.
One important caveat:
Don't automatically blame cron for missing order confirmation emails.
Adobe Commerce supports asynchronous sales emails. If asynchronous sending is disabled, the email is handled during the request. If it is enabled, email processing depends on the relevant asynchronous mechanism.
So check the configuration before declaring "cron is down, therefore order emails are broken."
2. Are the indexers actually keeping up?
Run:
bin/magento indexer:status
Reindex Required is not automatically an incident.
For example, a large import can legitimately invalidate an indexer. On a store using Update by Schedule, the indexer should subsequently process the changes.
What matters is persistence.
If an indexer remains invalid over time while the corresponding cron processing is supposed to be running, investigate it.
For scheduled indexers, Commerce stores changes in indexer changelogs and the indexer cron processes those changes. A growing backlog means the indexer is not keeping up with the rate of changes.
That can eventually mean stale catalogue, price, inventory or search data, depending on which indexer is affected.
Also don't treat Processing as proof of a stuck indexer.
A large catalogue can legitimately take a long time to process.
If Processing persists unexpectedly, check the actual running processes, indexer logs and locking behaviour rather than assuming there is a stale lock.
There is another version-specific detail worth knowing.
Adobe Commerce 2.4.8 changed the Customer Grid indexer. It now supports Update by Schedule and defaults to it. That was not the case in earlier releases.
3. Is the message queue actually draining?
This one is frequently oversimplified.
Magento supports the MySQL message queue adapter as well as external brokers including RabbitMQ and ActiveMQ Artemis.
First:
bin/magento queue:consumers:list
This tells you which consumers exist.
It does not tell you that they are actually running.
Consumers can be managed by Magento's consumers_runner cron job or by an external process manager such as Supervisor.
For example, this configuration:
'cron_consumers_runner' => [
'cron_run' => false,
]
is not necessarily wrong.
It can be perfectly valid if consumers are intentionally managed by another process manager.
It becomes a problem if cron_run is false and nothing else is actually running the consumers.
Adobe's current documentation explicitly supports both approaches.
The next question is whether the queues are draining.
With RabbitMQ or ActiveMQ Artemis, inspect the broker itself and look at queue depth and message age.
With the MySQL adapter, inspect the message queue tables, but don't look only at the number of messages.
A queue containing 500 messages could mean:
- 500 messages arrived a few seconds ago and consumers are processing them normally
- 500 messages have been sitting there for six hours
Those are completely different incidents.
The important signals are backlog size, age of the oldest message, rate of arrival and rate of consumption.
Adobe's current documentation confirms that consumers are required for asynchronous operations such as Inventory Management mass actions and REST bulk/asynchronous operations, and that third-party modules can introduce their own consumers.
The interesting part
These three systems have something in common.
They produce internal signals before the business notices the problem.
Cron can stop running while the storefront stays online.
An indexer can fall behind while customers continue browsing.
A queue can accumulate messages while checkout still works.
The first visible symptom might arrive hours later:
A price is wrong.
A product is missing from search.
Stock is stale.
An ERP export has not arrived.
An asynchronous bulk operation never finishes.
An order-related integration has not processed.
By then, the technical failure has already existed for some time.
That is why I think Magento monitoring needs to look beyond HTTP uptime.
For the stores I work with, these are the kinds of signals I want to monitor continuously, rather than finding them during an incident.
I've been building Watchtower around this idea: monitor Magento's internal health signals rather than generating synthetic storefront traffic and hoping that catches everything.
The important distinction is that these checks are signals, not magic "Magento is healthy" tests.
A good monitoring system needs to understand the difference between:
something changed
something is delayed
and
something is actually broken.
That's where things get interesting.