How to Monitor a Magento Store for Downtime

Your Magento store loads fine in the morning. Cron has been running. The admin panel works. The homepage and category pages render normally.

Then a deployment runs at 11 AM, the indexers don't finish, and the product pages start showing stale prices. Or Redis maxes out and adds 4 seconds to every page load. Or a third-party extension's API key expires and the cart silently rejects every checkout. Magento doesn't tell you any of this — it keeps returning 200s while revenue quietly leaks away.

Magento (and Adobe Commerce) is one of the most powerful ecommerce platforms in the world, and also one of the most operationally complex. PHP-FPM, Nginx or Apache, MySQL, Redis, Elasticsearch or OpenSearch, the message queue, indexers, cron, and a stack of extensions all have to keep working together for a single product page to render correctly.

This guide covers exactly what to monitor on a Magento store so you catch the failures that uptime checks miss.

Why Magento Needs Specific Monitoring

A Magento store has more moving parts than almost any other ecommerce platform:

Web tier — Nginx or Apache fronting PHP-FPM (or Litespeed)
PHP application — Magento 2 itself, plus Composer-managed dependencies
Database — MySQL or MariaDB, often with read replicas under load
Cache and session store — Redis (default in Magento 2.4+) or Memcached
Search engine — Elasticsearch or OpenSearch (mandatory in Magento 2.4+)
Message queue — RabbitMQ or the database queue for async jobs
Cron — Triggers indexers, queue consumers, scheduled tasks, and emails
Indexers — 9 separate indexers that keep prices, stock, search, and rules current
Varnish — Recommended full-page cache in front of PHP
CDN — Fastly (default for Adobe Commerce on cloud), Cloudflare, or others
Extensions — Often dozens of third-party modules, each capable of breaking checkout

Any one of those failing can break checkout while the rest of the site looks healthy. You need monitoring that watches the customer journey end-to-end.

What to Monitor

1) Storefront Availability

Start with the basics, but go beyond status codes:

Homepage — Verify it loads and contains your store name, navigation, and a featured product
Top category pages — At least one category page where bestsellers live; verify product count and pagination render
Featured product page — Your top SKU, with content validation for the product name and price
Search results — Magento search is powered by Elasticsearch; a broken Elasticsearch returns empty results without a 5xx

Use content validation, not just status codes. Magento's full-page cache will happily serve a 200 even when the underlying database or Elasticsearch is down — just an outdated cached page.

2) The Checkout Flow

This is where Magento revenue happens, and where the most expensive failures occur:

Cart page (/checkout/cart) — Verify it loads without JavaScript errors
Checkout page (/checkout) — Confirm the multi-step checkout renders all sections (shipping, payment, review)
Customer account (/customer/account/login) — Returning customers log in here
Place Order endpoint — While you can't fully test purchases, you can monitor that the underlying APIs respond

Validate that the checkout page contains expected text like "Shipping Address", "Payment Method", or your gateway's name. A blank or partial checkout (often caused by a broken extension's JavaScript) is the most common silent failure.

3) Indexer Health

Magento uses 9 indexers (catalog price, product, category, stock, etc.). When they get stuck, prices, stock, or product visibility go stale:

Heartbeat from a custom cron task that runs bin/magento indexer:status and pings a cron job monitor when all indexers report Ready
Alert on stuck reindex — Long-running indexer jobs are a leading indicator of database or Redis pressure

A stuck indexer means customers see yesterday's prices. Catch it the same hour, not the next morning.

4) Cron and Queue Consumers

Magento's cron is the engine behind almost every async behavior — emails, queue processing, scheduled imports, abandoned cart recovery, indexers.

Heartbeat monitoring for the main cron job (every 1 minute)
Per-consumer health — consumers_runner keeps queue consumers alive; monitor the queue depth and processing rate for product_action_attribute.update, inventory.source.items.cleanup, and others
Failed jobs alert — Watch the cron_schedule table for jobs in error or missed state

A backed-up queue is invisible from the storefront until the day a customer's order confirmation never arrives.

5) Custom Domain, SSL, and DNS

Domain-level issues take a Magento store fully offline:

DNS resolution — Verify your apex and www records resolve to the right backend (origin or CDN)
SSL certificate — Monitor expiry and chain validity; Adobe Commerce on cloud uses Fastly TLS that renews automatically, but on-prem Magento often relies on Let's Encrypt with renewal scripts that fail silently
HTTPS redirects — Confirm HTTP redirects to HTTPS without loops
CDN behavior — Verify your CDN (Fastly, Cloudflare, or similar) is serving cached pages and forwarding to origin correctly

See SSL Certificate Expiration: A Preventable Outage for why this is non-negotiable.

6) Performance

Magento is notoriously sensitive to performance regressions. A slow store doesn't just convert worse — Google demotes it in rankings.

TTFB on the homepage and a category page — Alert if median response time crosses 2x your normal baseline (see TTFB Monitoring: Diagnose Slow Server Response Times)
Cache hit ratio — A drop in Varnish or Fastly hit rate adds load to PHP and slows everything
Core Web Vitals — LCP, INP, and CLS on the storefront and key landing pages

7) Adobe Commerce Cloud Specifics

If you're on Adobe Commerce Cloud, you have additional infrastructure to watch:

Fastly health — Both edge and origin shielding
Multi-environment monitoring — Production, staging, and integration each have their own URLs
Deploy hooks — Cloud deploys run static content compile and database upgrades; failures here are silent unless you watch them
New Relic integration — Adobe Commerce Cloud bundles it; alerts on transaction time and error rate are essential

Common Magento Failure Modes

Failure	User Impact	How to Detect
Indexer stuck after import	Stale prices, missing products	Heartbeat with indexer:status
Redis memory exhausted	Slow site, sessions dropped, checkout broken	Cache cluster metrics + response time
Elasticsearch down	Search returns no results	Content validation on search results
Queue consumers stopped	Order emails delayed, inventory wrong	Queue depth metrics + heartbeat
Extension breaks checkout	Cart or checkout JavaScript errors	Content validation on /checkout
SSL certificate expired	Browser blocks visitors	SSL monitoring
Static content not compiled	404s on CSS/JS, broken layout	Content validation for known assets
Database connection pool exhausted	Intermittent 503s under load	Response time + 5xx rate alerts
Varnish cache flushed accidentally	Sudden TTFB spike, PHP overloaded	Cache hit ratio + TTFB monitoring
Magento upgrade scripts failed	Random 500s after deploy	Post-deploy validation

Monitoring by Magento Setup

On-prem / self-hosted

You own everything, so you must monitor everything:

Server-level — Disk space, memory, CPU on every node (web, DB, Redis, Elasticsearch)
Process-level — PHP-FPM pool saturation, queue consumer process count
Cron heartbeat every minute
MySQL slow query log alerting — Magento queries can become catastrophically slow as catalog grows

See Nginx Monitoring: Uptime, Errors, and Performance for the web tier.

Magento on managed hosting (Nexcess, MGT, Hypernode)

Hosts handle some monitoring, but not your store-specific behavior:

Checkout content validation — Hosts don't test that your checkout works
Extension health — Most hosting outages are caused by extension regressions, not the host
Staging-to-production parity — Monitor both environments to catch issues that only appear post-deploy

Adobe Commerce Cloud

All of the above, plus:
Fastly cache health at the edge
Cloud-specific log streams — Watch var/log and Fastly logs in production via the cloud CLI
Deploy hook output — Fail loudly when static content compile fails

Setting Up Monitoring for Your Magento Store

Quick start (10 minutes)

Homepage — https://yourstore.com with content validation for your store name
Featured product page — Top SKU with content validation for product title and price
Checkout — https://yourstore.com/checkout with content validation for "Shipping Address" and "Payment Method"
SSL — Automatic expiry alerts on your domain
Cron heartbeat — Add a task that pings a heartbeat URL every minute

Comprehensive setup (30 minutes)

Add to the quick start:

Cart page — /checkout/cart with content validation
Search results page — Confirm Elasticsearch is returning results
Customer login — /customer/account/login with content validation for the form
DNS — Verify domain resolution
Indexer status heartbeat — Custom cron that runs bin/magento indexer:status and pings a separate heartbeat
Queue consumer heartbeat — Critical consumers like inventory_index_* get individual heartbeats
Multi-region checks — Especially if you sell internationally

What to Do When Monitoring Detects an Issue

Store completely down (HTTP check fails):

Check your CDN / Fastly status — many "outages" are CDN issues, not origin
SSH or use the cloud CLI to check var/log/exception.log and var/log/system.log
Look at recent deploys; roll back if a deploy ran in the last hour
Check Redis and Elasticsearch — Magento 2.4+ won't even serve pages without a working search engine

Checkout broken (content validation fails on /checkout):

Check browser console on a real session for JavaScript errors
Disable recently updated extensions one at a time
Verify payment gateway extensions have current API keys
Run bin/magento cache:flush to rule out a stale cache after a config change

Slow response time alert:

Check Varnish / Fastly cache hit ratio — a drop usually means a config change invalidated the cache
Look at MySQL slow query log
Check Redis memory usage
Check indexers — a running reindex during peak traffic is a common cause

Indexer or queue alert:

Run bin/magento indexer:status to see which indexers are stuck
Check the queue depth for backed-up consumers
Look at MySQL deadlocks or long-running transactions
Restart the relevant queue consumer process

How Webalert Helps

Webalert monitors your Magento store the way customers experience it:

60-second checks from global regions — detect outages within 2 minutes
Content validation — verify checkout, cart, search, and product pages render correctly, not just return 200
SSL monitoring — catch certificate issues before browsers block your store
DNS monitoring — detect domain resolution failures
Cron and queue heartbeats — confirm Magento scheduled tasks and queue consumers keep firing
Response time tracking — catch slowdowns from extensions, indexers, or hosting before customers do
Multi-channel alerts — Email, SMS, Slack, Discord, Microsoft Teams, webhooks
Status pages — communicate incidents to customers and build trust
5-minute setup — paste your store URL and start monitoring

See features and pricing for details.

Summary

Magento has more failure points than almost any ecommerce platform — web tier, database, Redis, Elasticsearch, queue, indexers, cron, extensions, and CDN.
HTTP 200 doesn't mean your store works. Use content validation on cart, checkout, search, and key product pages.
Monitor cron, queue consumers, and indexers with heartbeats so silent background failures don't break customer-facing functionality.
SSL, DNS, and CDN issues take the entire store offline; monitor them separately.
Set tighter alerts immediately after deploys and extension updates.
Use a public status page to keep customers informed during incidents.

Magento gives you ecommerce power. Monitoring keeps the power on.

Stop losing sales to undetected store issues

Start monitoring with Webalert →

See features and pricing. No credit card required.