Monitoring Magento 2 / Adobe Commerce with Vigilmon

Magento 2 (and its enterprise sibling Adobe Commerce) is one of the most powerful — and most operationally complex — open source eCommerce platforms in the world. A production Magento 2 deployment isn't a single process; it's a fleet: PHP-FPM workers, MySQL, Elasticsearch, Redis, Varnish, RabbitMQ, and cron jobs, all of which must work in concert for a merchant's store to function. When any layer fails silently, the result is lost sales, degraded search, orphaned orders, or a merchant who can't log in to their admin panel. Vigilmon gives you visibility into every layer, from storefront uptime to checkout conversion health.

What You'll Set Up

• Magento storefront and admin panel HTTP health monitors
• MySQL database connectivity and slow-query alerting
• Elasticsearch / OpenSearch cluster health monitoring
• Redis FPC (Full Page Cache) and session store health
• Varnish cache hit rate monitoring
• RabbitMQ queue depth monitoring
• PHP-FPM pool utilization alerting
• Checkout conversion funnel health
• Magento cron job heartbeat monitoring

Prerequisites

• Magento 2.4+ (Open Source or Adobe Commerce) installed on a Linux server
• Access to the server running Magento (SSH or local shell)
• A free Vigilmon account

Why Monitoring Magento Is Non-Negotiable

A Magento 2 store that goes down during peak traffic doesn't just lose that hour's revenue — it may lose the customer permanently. But availability alone isn't the whole story:

• Elasticsearch down → product search returns no results; category pages show nothing. Shoppers see a broken store but the PHP app continues to report healthy.
• Redis FPC degraded → every page request hits PHP directly. A store that normally handles 500 RPS with Varnish + Redis may collapse under 50 RPS without the cache layer.
• RabbitMQ queue backlog → async order processing stalls; inventory reservations are not confirmed; orders may oversell.
• Cron failure → Magento indexers don't run, product data goes stale; newsletters queue but never send; order status emails are delayed.
• Admin unavailable → merchant staff can't process orders, update products, or issue refunds.

Vigilmon gives you monitors for each of these failure modes, alerting you before merchants and customers report the problem.

Step 1: Monitor the Magento Storefront

The storefront is the customer-facing website. Add three monitors — homepage, a representative category page, and a product page — to detect partial failures that wouldn't be caught by a single root-URL check.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your storefront homepage URL: https://yourstore.com.
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Under Advanced, enable Response time alert and set the threshold to 3000 ms (3 seconds).
7. Click Save.

Repeat for a category page (https://yourstore.com/women/tops.html) and a product page. Magento's layered navigation and EAV product model make category and product pages significantly heavier than the homepage — monitoring them separately surfaces rendering bottlenecks early.

Step 2: Monitor the Magento Admin Panel

Merchants need the admin panel to process orders and manage inventory. A healthy storefront combined with an inaccessible admin is a support emergency.

1. In Vigilmon, click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your admin URL: https://yourstore.com/admin (replace admin with your custom admin path if you've hardened it).
4. Set Expected HTTP status to 200.
5. Set Check interval to 2 minutes.
6. Enable Alert on status change so you're notified the moment the admin becomes unreachable.
7. Click Save.

Security note: Your Magento admin URL should already be a non-guessable path (e.g., /admin_xyz123). Vigilmon checks it from external probes — if you've IP-restricted the admin path, add Vigilmon's probe IPs to your server allowlist or use a private/internal monitor for this check.

Step 3: Monitor MySQL Database Health

All Magento merchant data — products, customers, orders, inventory — lives in MySQL. Create a custom health endpoint that validates DB connectivity:

<?php
// pub/health/db.php
$dsn = sprintf(
    'mysql:host=%s;port=%s;dbname=%s',
    getenv('DB_HOST') ?: 'localhost',
    getenv('DB_PORT') ?: '3306',
    getenv('DB_NAME') ?: 'magento'
);
try {
    $pdo = new PDO($dsn, getenv('DB_USER'), getenv('DB_PASS'));
    $pdo->query('SELECT 1');
    http_response_code(200);
    echo json_encode(['db' => 'ok']);
} catch (Exception $e) {
    http_response_code(503);
    echo json_encode(['db' => 'error', 'message' => $e->getMessage()]);
}

Place this file outside the Magento docroot's standard routing (use a separate VirtualHost or location block in nginx that restricts access by IP). Then:

1. In Vigilmon, add a new HTTP / HTTPS monitor.
2. URL: https://yourstore.com/health/db (or whatever internal path you've exposed).
3. Set Expected HTTP status to 200.
4. Set Check interval to 1 minute.
5. Set Alert on non-2xx status.

For slow query alerting, enable the MySQL slow query log:

# /etc/mysql/conf.d/magento.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

Use a Vigilmon cron heartbeat (Step 9) to monitor a slow-query log alerting script if you want proactive slow-query notification.

Step 4: Monitor Elasticsearch / OpenSearch

Magento 2.4+ requires Elasticsearch or OpenSearch for catalog search. A degraded Elasticsearch cluster causes product search failures and empty category pages.

Create a health endpoint that proxies the Elasticsearch cluster health API:

<?php
// pub/health/search.php
$esUrl = (getenv('ES_HOST') ?: 'http://localhost:9200') . '/_cluster/health';
$ch = curl_init($esUrl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
$response = json_decode(curl_exec($ch), true);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);

$status = $response['status'] ?? 'unknown';
if ($status === 'green' || $status === 'yellow') {
    http_response_code(200);
    echo json_encode(['search' => $status, 'shards' => $response['active_shards'] ?? 0]);
} else {
    http_response_code(503);
    echo json_encode(['search' => $status]);
}

In Vigilmon:

1. Add a new HTTP / HTTPS monitor for https://yourstore.com/health/search.
2. Set Expected HTTP status to 200.
3. Set Check interval to 2 minutes.
4. Set a Response body contains check for "search":"green" or "search":"yellow" — alert on red cluster status.

Step 5: Monitor Redis Cache and Session Store

Redis serves two critical Magento roles: Full Page Cache (FPC) and session storage. An FPC hit rate below 80% means most storefront requests are bypassing the cache and hitting PHP directly.

<?php
// pub/health/redis.php
$redis = new Redis();
$connected = @$redis->connect(
    getenv('REDIS_HOST') ?: '127.0.0.1',
    (int)(getenv('REDIS_PORT') ?: 6379),
    2.0
);
if (!$connected) {
    http_response_code(503);
    echo json_encode(['redis' => 'unreachable']);
    exit;
}

$info = $redis->info('stats');
$hits = (int)($info['keyspace_hits'] ?? 0);
$misses = (int)($info['keyspace_misses'] ?? 0);
$total = $hits + $misses;
$hitRate = $total > 0 ? round($hits / $total * 100, 1) : 0;

$status = $hitRate >= 80 ? 200 : 503;
http_response_code($status);
echo json_encode(['redis' => 'ok', 'hit_rate_pct' => $hitRate]);

In Vigilmon:

1. Add HTTP / HTTPS monitor for https://yourstore.com/health/redis.
2. Set Expected HTTP status to 200.
3. Add a Response time alert at 500 ms — a slow Redis response causes visible storefront lag.
4. The endpoint returns 503 when hit rate drops below 80%, automatically triggering a Vigilmon alert.

Step 6: Monitor Varnish Cache Hit Rate

If your Magento deployment uses Varnish, the cache hit rate is a direct measure of how much load Varnish is shielding from PHP. Add a backend stats endpoint:

#!/bin/bash
# /usr/local/bin/varnish-health.sh
STATS=$(varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss 2>/dev/null)
HITS=$(echo "$STATS" | grep MAIN.cache_hit | awk '{print $2}')
MISSES=$(echo "$STATS" | grep MAIN.cache_miss | awk '{print $2}')
TOTAL=$((HITS + MISSES))
if [ "$TOTAL" -gt 0 ]; then
    HIT_PCT=$(echo "scale=1; $HITS * 100 / $TOTAL" | bc)
else
    HIT_PCT=0
fi
echo "{\"varnish_hit_rate_pct\": $HIT_PCT}"

Expose this via a lightweight HTTP endpoint (e.g., a simple Python or Node.js stats server on an internal port) and add a Vigilmon monitor. Alert when Varnish hit rate drops below 85%, which indicates Magento cache invalidation is too aggressive or Varnish is misconfigured.

Step 7: Monitor RabbitMQ Queue Depth

Magento uses RabbitMQ for async order processing, inventory reservation, and catalog data export. A queue backlog means these operations are delayed.

<?php
// pub/health/rabbitmq.php
$host = getenv('RABBITMQ_HOST') ?: 'localhost';
$port = getenv('RABBITMQ_MGT_PORT') ?: '15672';
$user = getenv('RABBITMQ_USER') ?: 'guest';
$pass = getenv('RABBITMQ_PASS') ?: 'guest';

$url = "http://{$host}:{$port}/api/queues/%2F/async.operations.all";
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_USERPWD, "{$user}:{$pass}");
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
$response = json_decode(curl_exec($ch), true);
curl_close($ch);

$depth = (int)($response['messages'] ?? 0);
$status = $depth < 1000 ? 200 : 503;
http_response_code($status);
echo json_encode(['queue' => 'async.operations.all', 'depth' => $depth]);

In Vigilmon:

1. Add an HTTP / HTTPS monitor for https://yourstore.com/health/rabbitmq.
2. The endpoint returns 503 when queue depth exceeds 1000 — Vigilmon alerts automatically.
3. Set Check interval to 2 minutes.

Step 8: Monitor PHP-FPM Pool Utilization

PHP-FPM pool exhaustion causes Magento to return 502/504 errors under load. Monitor the active process percentage:

<?php
// pub/health/phpfpm.php
$socket = getenv('FPM_STATUS_URL') ?: 'http://127.0.0.1/php-fpm-status';
$ch = curl_init($socket . '?json');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 3);
$data = json_decode(curl_exec($ch), true);
curl_close($ch);

if (!$data) {
    http_response_code(503);
    echo json_encode(['fpm' => 'unreachable']);
    exit;
}

$active = (int)($data['active processes'] ?? 0);
$total = (int)($data['total processes'] ?? 1);
$utilPct = round($active / $total * 100, 1);
$status = $utilPct < 90 ? 200 : 503;
http_response_code($status);
echo json_encode(['fpm_utilization_pct' => $utilPct, 'active' => $active, 'total' => $total]);

Enable the PHP-FPM status page in your pool config:

; /etc/php/8.1/fpm/pool.d/www.conf
pm.status_path = /php-fpm-status

In Vigilmon, add a monitor for the PHP-FPM health endpoint. The endpoint returns 503 when pool utilization exceeds 90%, signaling that you need to increase pm.max_children.

Step 9: Monitor Magento Cron with Heartbeat Monitors

Magento relies heavily on cron for: catalog indexing, newsletter sending, order status emails, and inventory batch processing. A cron failure causes silent, cascading data staleness.

Set up a heartbeat monitor in Vigilmon:

1. In Vigilmon, click Add Monitor → Cron / Heartbeat.
2. Name it Magento Cron.
3. Set Expected interval to 5 minutes (matching Magento's default cron schedule).
4. Copy the heartbeat ping URL Vigilmon provides.

Add the ping to your Magento cron wrapper:

#!/bin/bash
# /usr/local/bin/magento-cron.sh
/usr/bin/php /var/www/magento/bin/magento cron:run 2>&1 | logger -t magento-cron
if [ $? -eq 0 ]; then
    curl -fsS "https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_TOKEN" > /dev/null
fi

Configure crontab:

* * * * * www-data /usr/local/bin/magento-cron.sh

Vigilmon alerts if no heartbeat ping arrives within the expected interval window, telling you cron has failed before any data staleness accumulates.

Step 10: Monitor Checkout Conversion Health

The checkout funnel is the most business-critical flow in any eCommerce store. Create an endpoint that reports recent order success rates from the Magento database:

<?php
// pub/health/checkout.php
try {
    $pdo = new PDO(
        sprintf('mysql:host=%s;dbname=%s', getenv('DB_HOST'), getenv('DB_NAME')),
        getenv('DB_USER'), getenv('DB_PASS')
    );
    // Orders placed in the last 10 minutes
    $stmt = $pdo->query("
        SELECT
            COUNT(*) as total,
            SUM(CASE WHEN status NOT IN ('error', 'canceled') THEN 1 ELSE 0 END) as successful
        FROM sales_order
        WHERE created_at >= DATE_SUB(NOW(), INTERVAL 10 MINUTE)
    ");
    $row = $stmt->fetch(PDO::FETCH_ASSOC);
    $total = (int)$row['total'];
    $successful = (int)$row['successful'];
    $errorRate = $total > 0 ? round(($total - $successful) / $total * 100, 1) : 0;
    $httpStatus = $errorRate <= 2 ? 200 : 503;
    http_response_code($httpStatus);
    echo json_encode(['checkout_error_rate_pct' => $errorRate, 'orders_10min' => $total]);
} catch (Exception $e) {
    http_response_code(503);
    echo json_encode(['checkout' => 'db_error']);
}

In Vigilmon, add a monitor for this endpoint. It returns 503 when checkout error rate exceeds 2% — the alert fires before a bad payment gateway or session misconfiguration silently kills conversion.

Recommended Alert Configuration

| Monitor | Alert Condition | Severity | |---|---|---| | Storefront homepage | Non-200 or p95 > 3s | Critical | | Category / product pages | Non-200 | High | | Admin panel | Non-200 | Critical | | MySQL health | Non-200 | Critical | | Elasticsearch health | Non-200 or red status | Critical | | Redis FPC | Non-200 (hit rate < 80%) | High | | Varnish hit rate | Below 85% | High | | RabbitMQ queue depth | > 1000 messages | High | | PHP-FPM utilization | > 90% | Critical | | Magento cron heartbeat | Missed for 10+ minutes | Critical | | Checkout error rate | > 2% | Critical |

Conclusion

Magento 2's power comes from its multi-tier architecture, but that same architecture creates multiple failure points that standard uptime monitoring won't catch. With Vigilmon covering storefront availability, MySQL, Elasticsearch, Redis, Varnish, RabbitMQ, PHP-FPM, cron, and checkout conversion, you have complete observability across the entire commerce stack. When something goes wrong — and in production eCommerce, something always eventually does — you'll know about it before your merchants or customers do.

Start monitoring your Magento 2 store at vigilmon.online.