How to Monitor Passbolt with Vigilmon (API Health, Email Delivery, Database, and SSL)

Passbolt is an open-source, self-hosted team password manager designed for collaboration. It stores, shares, and audits credentials across your organization, integrates with LDAP directories, and provides browser extensions for seamless autofill. Because Passbolt handles credential access for your entire team, downtime isn't just inconvenient — it can block engineers from accessing the credentials they need to respond to other incidents.

In this tutorial you'll set up end-to-end monitoring for Passbolt using Vigilmon — free tier, no credit card required.

Why Passbolt needs dedicated monitoring

Passbolt's failure modes are subtle and high-impact:

API unavailability — the Passbolt web app is a thick client that calls a REST API. If the API goes down, the UI loads but every credential operation silently fails. Users may see blank screens or spinning loaders before they realize something is wrong
Email delivery failures — Passbolt relies on email for invitation links, MFA recovery codes, and password sharing notifications. Silent SMTP failures mean users never receive credentials shared with them, and new team members can't activate their accounts
Database connectivity loss — Passbolt stores all credentials in a MySQL/MariaDB database. A database outage means no credentials can be read or written — but the web UI may still load, masking the severity of the failure
SSL certificate expiry — Passbolt enforces HTTPS strictly. Browser extensions and mobile apps refuse to connect to a Passbolt instance with an expired or self-signed certificate, cutting off all users at once
GPG key validation errors — Passbolt uses GPG for end-to-end encryption. Misconfigured key rings can cause the server health check to fail even when the underlying infrastructure is healthy

External monitoring catches all of these before your team notices.

What you'll need

A running Passbolt instance (CE, Pro, or Cloud, version 3.0 or later)
A free Vigilmon account (sign-up takes 30 seconds)
Your Passbolt server's public HTTPS URL

Step 1: Use Passbolt's built-in health check endpoint

Passbolt exposes a health check endpoint at /healthcheck/status.json. This endpoint verifies the core subsystems: database connectivity, GPG configuration, SSL, and application integrity.

Test it:

curl -sf https://passbolt.example.com/healthcheck/status.json

A healthy response looks like:

{
  "core": { "status": "OK" },
  "database": { "status": "OK" },
  "gpg": { "status": "OK" },
  "ssl": { "status": "OK" }
}

The endpoint returns HTTP 200 when all subsystems are healthy. If any subsystem reports a failure, it returns HTTP 500 — making it ideal for uptime monitoring.

Note: In some Passbolt versions this endpoint requires authentication or is only reachable from localhost. Check your Passbolt configuration under Administration → Healthcheck to verify it's accessible externally, or expose it through your reverse proxy.

Step 2: Set up HTTP health monitoring in Vigilmon

Log in to vigilmon.online and go to Monitors → New Monitor
Choose HTTP / HTTPS as the monitor type
Set the URL to: https://passbolt.example.com/healthcheck/status.json
Set the check interval to 1 minute
Under Expected response, configure:
- Status code: 200
Save the monitor

Vigilmon will probe this endpoint every minute. A database connectivity failure, GPG misconfiguration, or application error will cause the endpoint to return a non-200 status, triggering an immediate alert.

Step 3: Monitor the Passbolt web UI directly

The API health check covers backend subsystems, but monitoring the actual web UI path catches reverse proxy misconfigurations, asset delivery failures, and PHP-FPM issues that the health API might not surface.

In Vigilmon, go to Monitors → New Monitor
Choose HTTP / HTTPS
Set the URL to: https://passbolt.example.com/ (the login page)
Set the check interval to 2 minutes
Under Expected response, configure:
- Status code: 200
- Response body contains: Passbolt (or another string from your login page)
Save the monitor

This gives you an independent signal that the full application stack — not just the API — is serving requests correctly.

Step 4: Monitor email delivery with heartbeat checks

Passbolt's email queue is processed by a background worker (/bin/cake EmailQueue.sender). If this process stops running, all transactional emails — sharing notifications, MFA codes, account activations — queue up silently. Users never receive them.

Set up a Vigilmon heartbeat monitor to verify the email worker is running:

In Vigilmon, go to Monitors → New Monitor
Choose Heartbeat
Name it: "Passbolt email queue worker"
Set the expected interval to 5 minutes (ping every 5 min; alert if no ping in 10)
Copy the heartbeat ping URL

Then add a wrapper script or systemd drop-in that pings Vigilmon after each successful email queue flush:

#!/bin/bash
# /usr/local/bin/passbolt-email-monitor.sh
# Called by cron every 5 minutes alongside the email queue processor

# Check if the email queue worker process is alive
if pgrep -f "EmailQueue.sender" > /dev/null; then
  curl -sf "https://heartbeat.vigilmon.online/ping/your-heartbeat-id"
fi

Add to cron:

*/5 * * * * /usr/local/bin/passbolt-email-monitor.sh

If the email worker process dies, the ping stops, and Vigilmon alerts you after the grace window expires.

Step 5: Monitor database connectivity

Passbolt's health check endpoint validates database connectivity, but a dedicated database TCP check gives you an independent signal — and tells you whether a database issue is local (Passbolt can't reach DB) or external (DB port unreachable from outside).

If your Passbolt database is on the same host (or accessible externally on a non-default port), add a TCP monitor:

In Vigilmon, go to Monitors → New Monitor
Choose TCP Port
Enter your database server hostname: db.example.com
Enter port: 3306 (MySQL/MariaDB default)
Set check interval to 1 minute
Save the monitor

If your database is not externally accessible (which is the correct security posture), rely on the health check endpoint's database status field instead.

Step 6: Set up SSL certificate monitoring

Passbolt enforces HTTPS and browser extensions will refuse to connect if the certificate is expired or untrusted. Vigilmon's SSL monitoring gives you a 30-day warning before expiry.

In Vigilmon, go to Monitors → New Monitor
Choose SSL Certificate
Enter your Passbolt domain: passbolt.example.com
Set warning threshold to 30 days
Save the monitor

Given that a Passbolt certificate expiry is a complete service outage for all users and all browser extensions, the 30-day window gives you plenty of time to renew through Let's Encrypt or your CA.

Step 7: Configure alert channels

Passbolt is your team's credential store. An outage here has a disproportionate impact — engineers can't retrieve service passwords to address other incidents, and new employees can't activate accounts. Alerts should reach on-call staff immediately.

Webhook (Slack, PagerDuty, Discord):

Go to Alert Channels → Add Channel → Webhook
Enter your webhook URL
Assign to all Passbolt monitors

Email:

Go to Alert Channels → Add Channel → Email
Add your security or infrastructure team's email
Assign to all monitors

Set alert escalation under each monitor so that if Passbolt stays down for more than 5 minutes, a high-urgency page fires to PagerDuty or the on-call rotation.

Example Vigilmon alert payload for a Passbolt incident:

{
  "monitor_name": "Passbolt API health",
  "status": "down",
  "url": "https://passbolt.example.com/healthcheck/status.json",
  "started_at": "2026-03-10T14:35:00Z",
  "duration_seconds": 120
}

Step 8: Create an internal status page

A status page scoped to your team lets engineers check whether Passbolt is down without having to ask each other or file a ticket.

In Vigilmon, go to Status Pages → New Status Page
Name it "Security Tools" or "Passbolt Status"
Add your monitors: API health, web UI, email worker heartbeat, SSL cert, database TCP (if applicable)
Set visibility to internal or publish it to your team
Publish the page

Link to it from your team wiki under "Is Passbolt down?" so the first question has a self-service answer.

Recommended monitor summary

| Monitor | Type | Interval | Checks for | |---|---|---|---| | https://passbolt.example.com/healthcheck/status.json | HTTP | 1 min | API, database, GPG health | | https://passbolt.example.com/ | HTTP | 2 min | Web UI, reverse proxy, assets | | Passbolt email queue worker | Heartbeat | 5 min | Email delivery worker | | passbolt.example.com | SSL | daily | Certificate expiry | | db.example.com:3306 | TCP | 1 min | Database port reachability |

What's next

Backup verification heartbeats — if you run nightly Passbolt database exports (essential for a credential store), add a heartbeat monitor so you know when the backup job stops completing
Response time monitoring — the Passbolt API's response time under load can degrade before it returns errors; Vigilmon's latency history helps you spot this trend early

Get started free at vigilmon.online — no credit card, your first monitor is running in under a minute.