Why HTTP 200 Lies: Monitoring Magento for Silent Failures

The most dangerous Magento outage is the one your monitoring calls green. Your uptime tool pings the homepage every minute, gets a 200 OK, and stays quiet — while customers land on an empty category page, a broken checkout, or a search that returns nothing. The store is "up." It just isn't working.

These are silent failures: anything that returns HTTP 200 while the store is broken for customers. They're the failures generic uptime monitors are structurally unable to see, because they only ever ask one question — did the URL respond? — and the answer is yes.

The four classics

Almost every silent failure on a Magento store is one of these:

• A drifted indexer. The catalog or category indexer falls into an invalid or stuck state, and category pages render with zero products. Every page still returns 200. Customers see an empty shop.
• A dead overnight cron. cron:run dies at 3 a.m. Orders stop flowing to your ERP and pile up in the message queue; scheduled reindexes and emails stop. Nothing 500s — the work just silently stops happening.
• A front-end regression. A JavaScript error breaks the add-to-cart button after a deploy. The server happily serves 200s for every product page; no customer can put anything in their basket.
• A red search cluster. OpenSearch or Elasticsearch drops into red state and search returns an empty array. The search page loads fine (200) — it just never finds anything.

A status-code monitor calls all four of these healthy. That's not a misconfiguration; it's the ceiling of what an HTTP check can know.

"Is it up?" is the wrong question

It helps to see monitoring as three layers. Infrastructure APM (New Relic, Datadog) watches the server — CPU, memory, traces, PHP exceptions — and catches a silent failure only if it throws an exception, which most of these don't. Uptime monitors (Uptime Robot, Pingdom) watch whether the URL responds. Both are useful, and both sit above the thing that actually matters.

The question worth monitoring isn't "did the URL respond?" — it's "can a customer browse, search, and buy right now?" Answering it takes two things a status check doesn't have: a real browser, and a way to see inside Magento.

Catching them from outside: a real browser

Synthetic browser checks load the store in real Chromium — not a HEAD request — and actually walk the funnel: open a product, add to cart, go to cart, enter shipping, reach payment. Each step is timed independently, and the browser captures console.error and unhandled exceptions along the way. When a deploy breaks the add-to-cart button, the check fails at exactly that step and names the JavaScript error that caused it, instead of a vague "site down."

Selectors are the only fiddly part, and for Magento they're mostly solved: Luma and Hyvä ship as one-click presets, and custom themes drop their own CSS selectors in. Run that funnel every few minutes and a broken checkout surfaces in the time between two checks, not in the next morning's revenue report.

Catching them from inside: read Magento's own state

A browser sees what a customer sees, but some failures are upstream of the page — a cron about to cause a backlog, an indexer mid-drift, Redis evicting keys, PHP-FPM saturating its pool. To catch those before they reach a customer, you have to read Magento's internal state.

That's what a health endpoint does. Pulsar's optional read-only extension exposes /pulsar/health:

GET /pulsar/health
{
  "cron":    { "status": "ok",   "last_run": "34s ago" },
  "indexer": { "status": "warn", "detail": "catalog_category_product: invalid" },
  "queue":   { "status": "ok",   "pending": 12 },
  "search":  { "status": "crit", "detail": "OpenSearch cluster: red" }
}

Each of the 20 collectors maps to one failure mode — cron heartbeat, indexer state, queue depth, OpenSearch health, Redis evictions, PHP-FPM saturation, stuck pending_payment orders, SSL expiry, admin 2FA coverage, and more. The endpoint is read-only — it queries existing state and never writes back — and typically returns in under 50ms.

The point isn't more alerts

More monitoring usually means more noise, and noise is how teams end up muting the very alert that mattered. The trick is to map each alert to a real customer-facing failure and give every signal independent controls: per-collector overrides (Off / Critical-only / normal), a confirmation threshold so one blip doesn't page anyone, and a site-level mute for maintenance windows.

Monitor the business logic instead of the status code, and "the store is up" finally starts to mean "customers can buy."

See how Pulsar monitors Magento →