Part-DB Monitoring with Vigilmon: Uptime, API Health & Symfony Messenger Heartbeats

Your Part-DB price update job stopped running two weeks ago. Every component in your inventory now has stale pricing from a defunct supplier API. The web UI looked fine — everything was up — but the Symfony Messenger worker responsible for background jobs had quietly exited, and no one knew until an order was placed at the wrong price.

Part-DB is an open-source electronic components inventory management system built on PHP and Symfony, widely used by makers, electronics labs, repair shops, and small manufacturers to catalog and track components, manage storage locations, and maintain supplier information. Self-hosting Part-DB means owning the monitoring. Vigilmon gives you external HTTP monitors, keyword checks, SSL alerts, and heartbeat monitoring that cover every failure mode Part-DB exposes.

This tutorial walks you through complete Part-DB monitoring with Vigilmon.

What You'll Build

• An HTTP monitor on the Part-DB login page (web UI availability)
• An HTTP monitor on the /api/ REST endpoint (Symfony API Platform health)
• A keyword monitor to detect database connectivity failures
• SSL certificate expiry alerts for HTTPS Part-DB deployments
• A heartbeat monitor for Symfony Messenger workers (price updates, attachment cleanup)

Prerequisites

• A running Part-DB instance (self-hosted, v1.x recommended)
• A free account at vigilmon.online

Step 1: Monitor the Part-DB Login Page

The Part-DB login page is the entry point for all users. If it returns anything other than 200, no one can access the inventory system.

Test it first:

curl -o /dev/null -s -w "%{http_code}" https://your-partdb.example.com/en/login

Set up the Vigilmon monitor:

1. Log in to Vigilmon and click New Monitor → HTTP.
2. Set URL to https://your-partdb.example.com/en/login.
3. Set Check interval to 60 seconds.
4. Set Expected status code to 200.
5. Under Advanced → Keyword check, add:
   • Keyword present: Part-DB
6. Save the monitor.

The keyword check confirms you're receiving an actual Part-DB page rather than a reverse-proxy error page or a stale CDN response.

Step 2: Monitor the Part-DB REST API Endpoint

Part-DB ships with a REST API built on Symfony API Platform, available at /api/. An unauthenticated request to this endpoint returns a structured JSON-LD response (or a 401) that confirms the Symfony framework is alive and the database is reachable.

Test it:

curl -s https://your-partdb.example.com/api/

You should receive either a JSON-LD API description or a 401 Unauthorized response — both confirm the API layer is healthy. A 500 or 502 signals a PHP error or Nginx misconfiguration.

Set up the Vigilmon monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to https://your-partdb.example.com/api/.
3. Set Check interval to 60 seconds.
4. Under Advanced, set Expected status codes to 200,401 (both confirm a healthy API response).
5. Under Advanced → Keyword check, add:
   • Keyword present: api (matches the JSON-LD @context or Hydra context field)
6. Save the monitor.

If Part-DB's database becomes unreachable or a Symfony error is thrown before the response is assembled, the API returns a 500 — and Vigilmon fires an alert.

Step 3: Keyword Monitor for Database Connectivity

Part-DB stores all component data, storage locations, supplier information, and pricing in a MySQL or SQLite database. A keyword monitor on a data-loading page catches the scenario where the web server is up but the database has gone down — an HTTP status-code monitor alone would miss this.

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to https://your-partdb.example.com/en/ (or the root, which redirects to the parts list or login).
3. Set Expected status code to 200,302 (depending on your auth configuration).
4. Under Advanced → Keyword check, configure:
   • Keyword absent: SQLSTATE, An Error Occurred, PDOException, Connection refused
5. Save the monitor.

These absent keywords match Symfony's default exception page strings. If the database becomes unreachable, Symfony's error handler renders a page containing one of these strings, and Vigilmon fires immediately.

Step 4: SSL Certificate Monitoring

Part-DB is typically deployed behind Nginx or Apache with a Let's Encrypt certificate. Certificate auto-renewal can fail silently — Certbot may lose port-80 access, the systemd timer may be disabled, or disk space may run out. A lapsed certificate immediately breaks access for all users.

Configure SSL alerting on your existing monitors:

1. Open the HTTP monitor from Step 1 (login page).
2. Click Edit → Advanced → SSL Certificate.
3. Set Alert when certificate expires in less than: 14 days.
4. Save.

Repeat for the API monitor from Step 2. Two monitors watching the certificate gives you redundancy in case one monitor endpoint experiences an unrelated outage during the cert check.

Step 5: Heartbeat Monitor for Symfony Messenger Workers

Part-DB relies on Symfony Messenger for background processing — including automated price updates from supplier APIs and attachment file cleanup. These workers run as long-lived processes, typically managed by supervisor or a systemd service.

If the Messenger worker crashes or is inadvertently stopped (e.g., after a server reboot where the supervisor service failed to start), price updates silently stop. The web UI remains fully functional while the background job queue fills up with unprocessed messages.

Set up a Vigilmon Heartbeat monitor:

1. Click New Monitor → Heartbeat in Vigilmon.
2. Give it a name like Part-DB Messenger Worker.
3. Set Expected interval to 10 minutes.
4. Copy the generated heartbeat URL: https://vigilmon.online/ping/<your-unique-token>.
5. Save the monitor.

Wire the heartbeat into your worker setup:

The cleanest approach is a small custom Symfony Messenger middleware or a scheduled command that pings Vigilmon. Add a console command to src/Command/HeartbeatCommand.php:

<?php
namespace App\Command;

use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\HttpClient\HttpClient;

class HeartbeatCommand extends Command
{
    protected static $defaultName = 'app:heartbeat';

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $client = HttpClient::create();
        $client->request('GET', 'https://vigilmon.online/ping/<your-unique-token>');
        return Command::SUCCESS;
    }
}

Then add a cron entry to call this command every 10 minutes:

*/10 * * * * cd /path/to/part-db && php bin/console app:heartbeat >> /dev/null 2>&1

Alternatively, if you want the heartbeat to confirm the Messenger worker is alive (not just the cron), wrap the ping in a supervisor event listener that pings on each successful message dispatch. For most deployments, the cron approach is simpler and sufficient.

If Vigilmon does not receive a ping within 10 minutes (plus configured grace period), it fires an alert — confirming your price update and cleanup jobs are no longer processing.

Step 6: Alert Channels

Go to Notifications → New Channel in Vigilmon and configure:

• Email — direct alerts to your lab or operations team
• Webhook — post to Slack, Discord, or a ticketing system

Example Part-DB downtime alert:

🔴 DOWN: Part-DB Login Page (your-partdb.example.com)
Status: 502 Bad Gateway
Region: EU-West
Triggered: 2026-04-02 14:23 UTC

Example heartbeat alert:

🔴 MISSING HEARTBEAT: Part-DB Messenger Worker
Last ping received: 1 hour 12 minutes ago
Expected every: 10 minutes

Step 7: Status Page

Go to Status Pages → New Status Page in Vigilmon. Add all Part-DB monitors and publish:

<a href="https://vigilmon.online/status/<your-slug>">
  <img src="https://vigilmon.online/badge/<monitor-slug>" alt="Part-DB Status" />
</a>

What You've Built

| Failure scenario | How Vigilmon catches it | |---|---| | Web server (Nginx/Apache) down | HTTP monitor on /en/login detects non-200 | | PHP-FPM crash | API monitor on /api/ detects 502/503 | | MySQL/SQLite unreachable | Keyword monitor catches SQLSTATE/PDOException in response | | Symfony app error (500) | API monitor fires on unexpected 500 status | | SSL certificate expiry | SSL alert fires 14 days before expiry | | Symfony Messenger worker stopped | Heartbeat monitor fires when pings stop arriving | | Price updates silently failing | Heartbeat monitor (Messenger worker) catches the failure |

Part-DB keeps your components organized — but a silent background job failure or an unnoticed SSL expiry can disrupt your lab workflow at the worst time. Vigilmon monitors your Part-DB instance from outside your network, giving you the alert before your team hits an error page.

Start monitoring your Part-DB instance today — register free at vigilmon.online.