Monitoring that only checks uptime is mostly blind
Most stores have monitoring, and most of that monitoring answers one question: is the homepage returning a 200. That is worth knowing, and it is a small fraction of what actually breaks.
The failures that hurt a Magento store rarely take the homepage down. Checkout breaks, orders stop flowing, a cron job dies, and the uptime check stays green the whole time.
This article covers the three questions real observability should answer, and the specific gaps that leave teams blind to problems customers are already feeling.
The three questions observability should answer
Good observability answers three separate questions, and most setups only cover the first. Is the store up, is it actually working, and when it breaks, why.
Uptime monitoring answers the first. Business and error-rate signals answer the second. Logs, traces, and metrics answer the third.
A gap in any one of them shows up as slow detection or slow diagnosis. You either find out late that something is wrong, or you know it is wrong and cannot tell why.
Errors your Magento logs never see
Teams assume the application log captures the failures, and a large share of them never reach it. A PHP fatal that kills a request writes to the PHP-FPM or web server log, not to exception.log.
Server-level 500s, timeouts, and out-of-memory kills often leave no trace in Magento's own logging at all. If your observability only reads the Magento logs, those failures are invisible to you.
The business signals nobody watches
The most important alarm on an ecommerce store is not a server metric. It is a drop in completed orders.
A store can serve every page correctly while checkout quietly fails for a segment of customers, and no infrastructure alert will fire. The only signal is that orders per hour fell off a cliff.
Watching order rate, checkout success, and payment failure rate catches revenue-affecting problems that server monitoring is structurally blind to. These are the signals that map to what the business actually feels.
Background work has no alarm by default
Magento's background systems fail silently unless something is watching them. Cron, indexers, and message-queue consumers can all stop working while the storefront keeps serving pages.
None of these raises an alert on its own. A stalled cron, a growing queue backlog, or a disk creeping toward full will each take the store down eventually, with no warning unless you monitor them:
- Cron and indexer health, so stale data and unsent email surface before customers notice.
- Message-queue depth, so a stuck consumer is caught while the backlog is small.
- Disk space and inode usage, so a full partition never arrives as a surprise.
Each of these is cheap to watch and expensive to miss.
Time to detect and time to diagnose
Two numbers measure how good your observability really is. Time to detect is how long between a failure starting and someone knowing. Time to diagnose is how long between knowing and understanding why.
Uptime-only monitoring makes both numbers bad. You detect late, because the check does not see the failure, and you diagnose slowly, because there are no traces or aggregated logs to read.
Every gap you close moves one of those numbers down. A synthetic checkout test cuts time to detect, and searchable, aggregated logs cut time to diagnose. Both translate directly into shorter incidents.
Closing the gaps
Closing observability gaps does not require a large platform. It requires covering all three questions instead of just uptime.
A synthetic checkout test confirms the store works, not just that it responds. Error-rate alerts on the server logs catch what Magento does not record. Cron, queue, and disk checks watch the background work, and log aggregation makes the whole picture searchable when you need to diagnose.
None of that is exotic. It is a handful of checks aimed at the failures that actually happen, rather than the one failure that is easiest to monitor.
Start with the single check that would have caught your last incident, and build from there. Observability grows well one real failure mode at a time, and each addition pays for itself the next time that mode recurs.
You cannot fix what you cannot see
Every minute of delay between a failure and its detection is a minute of lost orders or degraded experience. Observability gaps turn a five-minute incident into an hour-long one, because nobody knew until a customer complained.
Knowing what your current logging and monitoring actually capture, and more importantly what they miss, is the difference between finding problems and being told about them. Mapping those gaps is one of the most practical outcomes a platform review can deliver.