tutorial

Monitoring Pimcore with Vigilmon

Pimcore is an enterprise open-source Digital Experience Platform combining PIM, DAM, CMS, and e-commerce — but Admin UI outages, REST API failures, Symfony Messenger worker stalls, and database connectivity issues silently break content workflows and integrations. Here's how to monitor Pimcore availability, API endpoints, background workers, and SSL certificates with Vigilmon.

Pimcore is an enterprise-grade open-source Digital Experience Platform built on PHP and Symfony. It combines Product Information Management (PIM), Digital Asset Management (DAM), a full CMS, and e-commerce capabilities in a single platform — used by global brands to manage product catalogs, digital assets, and multichannel content pipelines. When the Pimcore Admin UI goes down, editors cannot publish content or update product data. When the REST API endpoint fails, downstream integrations — PIM-to-ERP sync, DAM webhook consumers, headless frontend apps — fail silently. When Symfony Messenger workers stop processing, asset thumbnail generation queues up and search index updates fall behind, causing stale data to surface in production storefronts. Vigilmon gives you external monitoring for Pimcore's Admin UI, REST API, database connectivity, background workers, and SSL certificates so you catch failures before they reach your content team or external integrations.

What You'll Set Up

  • Pimcore Admin UI availability via HTTP keyword check
  • REST API endpoint availability (/api/webservices/)
  • Database connectivity check via HTTP response
  • Symfony Messenger worker health via cron heartbeats
  • SSL certificate expiry alerts for HTTPS deployments

Prerequisites

  • Pimcore 11.x or 10.x running on a server you control
  • Shell access to the Pimcore host
  • A free Vigilmon account

Step 1: Monitor the Pimcore Admin UI

The Pimcore Admin UI at /admin/login is the primary interface for editors, marketers, and content managers. When PHP-FPM crashes, the web server misconfigures a rewrite rule, or a Pimcore upgrade breaks the routing layer, the Admin UI returns a blank page or 500 error — and editors have no way to publish or update content. Monitor Admin UI availability from outside your network:

  1. In Vigilmon, click Add Monitor → HTTP Keyword.
  2. Set the URL to https://your-pimcore-domain.com/admin/login.
  3. Set Keyword to Pimcore (appears in the login page title).
  4. Set Check interval to 2 minutes.
  5. Set Alert after 2 consecutive failures.

Vigilmon will load the login page every 2 minutes and verify the Pimcore keyword is present. A 500 error, blank page, or missing keyword triggers an alert before any editor notices the Admin UI is down.

For Pimcore instances behind Basic Auth or an IP allowlist, add an internal HTTP check instead:

#!/bin/bash
# /usr/local/bin/pimcore-admin-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/abc123"
PIMCORE_URL="https://your-pimcore-domain.com/admin/login"
EXPECTED_KEYWORD="Pimcore"
TIMEOUT=15

HTTP_RESPONSE=$(curl -s --max-time "$TIMEOUT" -L "$PIMCORE_URL")
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time "$TIMEOUT" -L "$PIMCORE_URL")

if [ "$HTTP_CODE" != "200" ]; then
  echo "Admin UI returned HTTP $HTTP_CODE"
  exit 1
fi

if echo "$HTTP_RESPONSE" | grep -q "$EXPECTED_KEYWORD"; then
  echo "Admin UI OK: keyword '$EXPECTED_KEYWORD' found"
  curl -s "$HEARTBEAT_URL"
else
  echo "Admin UI keyword '$EXPECTED_KEYWORD' missing — possible render failure"
  exit 1
fi

Install as a cron heartbeat:

chmod +x /usr/local/bin/pimcore-admin-check.sh
(crontab -l 2>/dev/null; echo "*/2 * * * * /usr/local/bin/pimcore-admin-check.sh >> /var/log/pimcore-admin-health.log 2>&1") | crontab -

Step 2: Monitor the Pimcore REST API

Pimcore's REST API at /api/webservices/ powers external integrations — ERP product data ingestion, headless frontend content delivery, and third-party DAM connectors. A failed REST API means integration jobs begin failing silently, product catalogs go stale, and frontend apps serve outdated content. Monitor the API endpoint directly:

#!/bin/bash
# /usr/local/bin/pimcore-api-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/def456"
PIMCORE_URL="https://your-pimcore-domain.com"
API_KEY="your-pimcore-api-key"
TIMEOUT=15

# Check the webservices endpoint responds with valid JSON
API_RESPONSE=$(curl -s \
  --max-time "$TIMEOUT" \
  -H "Accept: application/json" \
  "${PIMCORE_URL}/api/webservices/?apikey=${API_KEY}&type=object&id=1")

HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
  --max-time "$TIMEOUT" \
  -H "Accept: application/json" \
  "${PIMCORE_URL}/api/webservices/?apikey=${API_KEY}&type=object&id=1")

if [ "$HTTP_CODE" = "200" ] || [ "$HTTP_CODE" = "404" ]; then
  # 404 on a missing object is still a valid API response — the endpoint itself is up
  echo "REST API OK: HTTP $HTTP_CODE"
  curl -s "$HEARTBEAT_URL"
else
  echo "REST API failed: HTTP $HTTP_CODE"
  exit 1
fi

For Pimcore 11 with the DataHub or REST Data Provider bundle:

# Check the REST API ping endpoint (if enabled)
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
  --max-time 15 \
  -H "X-API-Key: your-api-key" \
  "https://your-pimcore-domain.com/api/ping")

if [ "$HTTP_CODE" = "200" ]; then
  echo "REST API ping OK"
  curl -s "https://vigilmon.online/heartbeat/def456"
else
  echo "REST API ping failed: HTTP $HTTP_CODE"
  exit 1
fi

Set the Vigilmon heartbeat to 3 minutes. REST API failures that persist beyond one check cycle need immediate attention — integration jobs waiting on the API will begin accumulating in their own retry queues.

Step 3: Monitor Database Connectivity

Pimcore uses MySQL/MariaDB for all structured data — objects, documents, assets metadata, user sessions, and workflow states. A lost database connection causes cascading failures: the Admin UI throws 500 errors, the REST API returns 503, and Symfony Messenger workers stop processing. Monitor database connectivity via a lightweight PHP health endpoint on the Pimcore host:

Create a health check endpoint at your web root:

<?php
// web/health/db.php — restrict access by IP or secret token in production

$dbHost = getenv('PIMCORE_DB_HOST') ?: 'localhost';
$dbName = getenv('PIMCORE_DB_DATABASE') ?: 'pimcore';
$dbUser = getenv('PIMCORE_DB_USERNAME') ?: 'pimcore';
$dbPass = getenv('PIMCORE_DB_PASSWORD') ?: '';

try {
    $pdo = new PDO("mysql:host=$dbHost;dbname=$dbName", $dbUser, $dbPass, [
        PDO::ATTR_TIMEOUT => 5,
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    ]);
    $pdo->query('SELECT 1');
    http_response_code(200);
    echo json_encode(['status' => 'ok', 'db' => 'connected']);
} catch (Exception $e) {
    http_response_code(503);
    echo json_encode(['status' => 'error', 'message' => 'database unreachable']);
}

Then monitor it with Vigilmon:

  1. In Vigilmon, click Add Monitor → HTTP Keyword.
  2. Set URL to https://your-pimcore-domain.com/health/db.php.
  3. Set Keyword to connected.
  4. Set Check interval to 2 minutes.

Alternatively, check database connectivity from the shell using Pimcore's Symfony console:

#!/bin/bash
# /usr/local/bin/pimcore-db-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/ghi789"
PIMCORE_ROOT="/var/www/pimcore"

# Use Doctrine's built-in connection check via Symfony console
if php "$PIMCORE_ROOT/bin/console" doctrine:query:sql "SELECT 1" --env=prod > /dev/null 2>&1; then
  echo "Database connectivity OK"
  curl -s "$HEARTBEAT_URL"
else
  echo "Database connectivity FAILED"
  exit 1
fi

chmod +x /usr/local/bin/pimcore-db-check.sh
(crontab -l 2>/dev/null; echo "*/2 * * * * /usr/local/bin/pimcore-db-check.sh >> /var/log/pimcore-db-health.log 2>&1") | crontab -

Step 4: Monitor Symfony Messenger Workers

Pimcore uses Symfony Messenger for all background processing: asset thumbnail generation, full-text search index updates, email dispatch, workflow transition notifications, and scheduled maintenance jobs. Messenger workers run as long-lived processes — when they crash (OOM, uncaught exception, or systemd kill), the message queue accumulates without processing. Editors see stale thumbnails, search results go out of date, and emails queue indefinitely.

Monitor worker health via cron heartbeats:

#!/bin/bash
# /usr/local/bin/pimcore-worker-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/jkl012"
WORKER_SERVICE="pimcore-messenger"   # systemd service name, adjust to your setup

# Check the Messenger worker process is running
if systemctl is-active --quiet "$WORKER_SERVICE" 2>/dev/null; then
  echo "Messenger worker active via systemd"
  curl -s "$HEARTBEAT_URL"
elif pgrep -f "messenger:consume" > /dev/null; then
  echo "Messenger worker process found"
  curl -s "$HEARTBEAT_URL"
else
  echo "Messenger worker not running — queue processing stalled"
  exit 1
fi

For queue depth monitoring (requires database access):

#!/bin/bash
# /usr/local/bin/pimcore-queue-depth-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/mno345"
DB_HOST="${PIMCORE_DB_HOST:-localhost}"
DB_NAME="${PIMCORE_DB_DATABASE:-pimcore}"
DB_USER="${PIMCORE_DB_USERNAME:-pimcore}"
DB_PASS="${PIMCORE_DB_PASSWORD:-}"
MAX_QUEUE_DEPTH=500
TIMEOUT=10

QUEUE_DEPTH=$(mysql -h "$DB_HOST" -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" \
  --connect-timeout="$TIMEOUT" \
  -sN -e "SELECT COUNT(*) FROM messenger_messages WHERE delivered_at IS NULL" 2>/dev/null || echo -1)

if [ "$QUEUE_DEPTH" -eq -1 ]; then
  echo "Could not query messenger queue depth"
  exit 1
elif [ "$QUEUE_DEPTH" -le "$MAX_QUEUE_DEPTH" ]; then
  echo "Messenger queue OK: $QUEUE_DEPTH messages pending"
  curl -s "$HEARTBEAT_URL"
else
  echo "Messenger queue backed up: $QUEUE_DEPTH messages pending (max: $MAX_QUEUE_DEPTH)"
  exit 1
fi

Set up cron jobs and Vigilmon heartbeats at 2 minutes for the worker health check and 5 minutes for queue depth. A backed-up Messenger queue that correlates with a missing worker process confirms the worker crashed — restart it and investigate the crash cause in Symfony logs (/var/www/pimcore/var/log/prod.log).

Step 5: Monitor SSL Certificates

Enterprise Pimcore deployments always run HTTPS — expired certificates cause browsers to block access to the Admin UI and break API clients that enforce certificate validation. Monitor SSL certificate expiry before it impacts operations:

  1. In Vigilmon, click Add Monitor → SSL Certificate.
  2. Set Domain to your-pimcore-domain.com.
  3. Set Alert before expiry to 14 days (allow time for renewal).

For Pimcore deployments with multiple domains (multi-site CMS setups), add a separate SSL monitor for each domain. Certificate expiry on a secondary site's domain can silently break that site's frontend while the Admin UI remains accessible.

You can also monitor certificate validity from the Pimcore host:

#!/bin/bash
# /usr/local/bin/pimcore-ssl-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/pqr678"
DOMAIN="your-pimcore-domain.com"
MIN_DAYS_REMAINING=14

EXPIRY_DATE=$(echo | openssl s_client -servername "$DOMAIN" \
  -connect "${DOMAIN}:443" 2>/dev/null | \
  openssl x509 -noout -enddate 2>/dev/null | \
  cut -d= -f2)

if [ -z "$EXPIRY_DATE" ]; then
  echo "Could not retrieve SSL certificate for $DOMAIN"
  exit 1
fi

EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s 2>/dev/null || \
  date -j -f "%b %d %T %Y %Z" "$EXPIRY_DATE" +%s 2>/dev/null)
NOW_EPOCH=$(date +%s)
DAYS_REMAINING=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ "$DAYS_REMAINING" -ge "$MIN_DAYS_REMAINING" ]; then
  echo "SSL OK: $DAYS_REMAINING days until expiry ($EXPIRY_DATE)"
  curl -s "$HEARTBEAT_URL"
else
  echo "SSL WARNING: $DAYS_REMAINING days remaining (threshold: $MIN_DAYS_REMAINING)"
  exit 1
fi

Run this check daily with a 25 hour Vigilmon heartbeat interval.

Step 6: Set Up Alert Channels

Configure Vigilmon to route Pimcore alerts to the right teams:

  1. Go to Alert Channels in Vigilmon.
  2. Add a Slack webhook to #pimcore-ops for Admin UI and API monitors.
  3. Add PagerDuty for the database connectivity monitor — a lost database connection takes down the entire platform.
  4. Add email notification for the Messenger queue depth monitor — queue buildup is a performance issue, not always an emergency.
  5. Set Consecutive failures before alert to 1 for Admin UI and REST API monitors. Pimcore failures are rarely transient — a 500 error usually indicates a real problem.

Add maintenance windows during Pimcore upgrades or Symfony dependency updates:

curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "monitor_id": "PIMCORE_ADMIN_MONITOR_ID",
    "duration_minutes": 30,
    "reason": "Pimcore version upgrade"
  }'

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP keyword (Admin UI) | /admin/login | PHP-FPM crash, routing failure, 500 errors | | HTTP keyword (REST API) | /api/webservices/ | API endpoint failure, integration breakage | | HTTP keyword (database) | /health/db.php | Database connection loss, MySQL crash | | Cron heartbeat (Messenger worker) | systemctl / pgrep | Worker crash, queue processing stall | | Cron heartbeat (queue depth) | messenger_messages table | Queue accumulation, worker capacity | | SSL certificate | your-pimcore-domain.com | Certificate expiry before renewal |

Pimcore's failure modes are often silent from an operational standpoint — a crashed Messenger worker doesn't alert editors, a database connection loss shows as a cryptic 500 in the Admin UI rather than a system alert, and REST API failures accumulate as silent integration errors in downstream systems. External monitoring with Vigilmon gives you visibility before editors, API consumers, or storefront customers notice anything is wrong.

Start monitoring for free at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles