Monitoring Cachet Status Page with Vigilmon

Cachet is the leading open-source status page system: a public-facing page with component statuses (operational / degraded / partial outage / major outage), incident announcements, scheduled maintenance notices, metric graphs, and email subscriber notifications — a fully self-hosted Statuspage.io alternative with no per-subscriber costs and complete data ownership. Built on PHP/Laravel, Cachet is deployed on Linux or Docker and exposes a REST API for automated incident creation and component status updates. The cruel irony of a status page is that it is most needed precisely during an outage — if Cachet itself goes down during an incident, your customers have no authoritative source to check and will flood your support channels instead. Vigilmon gives you external monitoring for Cachet's web UI, its built-in health check endpoint, component API health, queue worker process liveness, and SSL certificate expiry so your status page remains available when your customers need it most.

What You'll Set Up

• Cachet status page web UI availability via HTTP monitor
• /api/v1/ping built-in health endpoint availability and pong response check
• Component API health via /api/v1/components endpoint
• Queue worker liveness via cron heartbeat
• SSL certificate expiry alerts for HTTPS Cachet deployments

Prerequisites

• Cachet running via Docker or native Laravel deployment on port 8000
• A Cachet API token (from user settings in the Cachet admin panel)
• A free Vigilmon account

Step 1: Monitor the Cachet Status Page Web UI

The Cachet status page root URL is the public-facing page your customers visit. Monitor it externally to confirm Cachet is serving the public status page correctly:

1. In Vigilmon, click Add Monitor → HTTP/HTTPS.
2. Enter your Cachet URL: http://your-server:8000/ (or https://status.yourdomain.com/ if using a custom domain).
3. Set Check interval to 2 minutes.
4. Set Expected HTTP status to 200.
5. Under Response body check, add a keyword that appears on your Cachet status page (e.g., your company name, or the word Components which appears on all Cachet status pages).
6. Click Save.

The body keyword check prevents a false positive when a reverse proxy returns 200 with an error page instead of the actual Cachet content. Nginx returning a cached "502 Bad Gateway" page with a 200 status code would pass a status-code-only check but fails when the expected Cachet content keyword is absent.

If you have configured Cachet under a subdirectory path (e.g., https://yourdomain.com/status/), use the full path including the subdirectory for the monitor URL.

Step 2: Monitor the /api/v1/ping Built-in Health Endpoint

Cachet ships with a dedicated health check endpoint at /api/v1/ping that returns {"data": "pong"} when the application and database layers are functioning correctly. This endpoint is specifically designed for load balancer health checks and monitoring probes — use it as the authoritative liveness check for Cachet:

1. In Vigilmon, click Add Monitor → HTTP/HTTPS.
2. Enter the ping URL: http://your-server:8000/api/v1/ping
3. Set Check interval to 2 minutes.
4. Set Expected HTTP status to 200.
5. Under Response body check, add keyword: pong
6. Click Save.

This is the most reliable single monitor for Cachet health — it exercises the full Laravel application stack including the database connection. Verify the endpoint manually before setting up the monitor:

curl -s http://your-server:8000/api/v1/ping
# Expected: {"data":"pong"}

If the endpoint returns anything other than {"data":"pong"} — including a Laravel error page, a database connection error, or a 500 status — the Vigilmon body check fails and triggers an alert. Unlike the root status page URL, this endpoint is designed to return minimal, predictable JSON, so false positives from cosmetic page changes are not a concern.

Step 3: Monitor Component Count via /api/v1/components

Cachet's components endpoint returns the list of all configured service components with their current statuses. Monitoring this endpoint confirms that the Cachet API is serving component data — not just that the application is alive, but that the core status page data layer is intact:

1. In Vigilmon, click Add Monitor → HTTP/HTTPS.
2. Enter the components URL: http://your-server:8000/api/v1/components
3. Set Check interval to 5 minutes.
4. Set Expected HTTP status to 200.
5. Under Response body check, add keyword: data (the root key of the JSON response containing the component array).
6. Under Request headers, add: X-Cachet-Token: your-api-token (optional for public components, required if you have restricted API access).
7. Click Save.

A valid components response looks like:

{
  "data": [
    {
      "id": 1,
      "name": "API",
      "status": 1,
      "status_name": "Operational",
      ...
    }
  ],
  "meta": {
    "pagination": { ... }
  }
}

For public Cachet deployments without API authentication, this endpoint is accessible without an API token. For private deployments, obtain your API token from Cachet's admin panel under Users → your account → API Token.

Step 4: Monitor Queue Worker Liveness via Cron Heartbeat

Cachet uses Laravel queues for processing subscriber notifications and incident creation webhooks. The queue worker (php artisan queue:work) runs as a background process — when it exits silently, subscribers stop receiving notification emails for status updates and incident reports. This failure is invisible from the web UI: the status page continues to serve content and accept API incident updates, but no notifications are delivered. Monitor the queue worker externally:

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set Expected ping interval to 5 minutes.
3. Copy the heartbeat URL (e.g., https://vigilmon.online/heartbeat/abc123).

Create a queue worker health check script:

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

HEARTBEAT_URL="https://vigilmon.online/heartbeat/abc123"

# Check for the Laravel queue worker process
# Adjust the process name match to your deployment method

# For native PHP deployment:
WORKER_NATIVE=$(pgrep -f "queue:work" | wc -l)

# For Docker deployment:
WORKER_DOCKER=$(docker compose -f /path/to/docker-compose.yml ps queue 2>/dev/null | grep -c "Up" || echo 0)

WORKER_RUNNING=$(( WORKER_NATIVE + WORKER_DOCKER ))

if [ "$WORKER_RUNNING" -gt 0 ]; then
  echo "Cachet queue worker running (${WORKER_RUNNING} process(es))"
  curl -s "$HEARTBEAT_URL"
else
  echo "Cachet queue worker not running - subscriber notifications will not fire"
  exit 1
fi

Install as a cron job:

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

For Docker Compose deployments, the queue service is typically defined as a separate container in your docker-compose.yml:

services:
  queue:
    image: cachethq/docker:latest
    command: php artisan queue:work --sleep=3 --tries=3
    depends_on:
      - db
    env_file: .env

Check the container name in your compose file and update the docker compose ps command to match.

Step 5: SSL Certificate Monitoring for HTTPS Cachet Deployments

Public-facing status pages almost always use HTTPS — customers expect a secure connection, and modern browsers warn on non-HTTPS pages. An expired SSL certificate on your status page is a serious problem during an incident: at the exact moment customers need status information, their browser shows a security warning instead. Monitor certificate expiry proactively:

1. In Vigilmon, click Add Monitor → SSL Certificate.
2. Enter your Cachet hostname: status.yourdomain.com
3. Set Alert when certificate expires in less than 21 days (slightly longer than typical for a customer-facing status page — the cost of expiry is high).
4. Set Check interval to 1 day.
5. Click Save.

If your Cachet instance is accessible via multiple domains (e.g., status.yourdomain.com and yourdomain.com/status), add an SSL monitor for each domain separately.

For Let's Encrypt certificates managed by Certbot, renewal typically occurs 30 days before expiry. Setting the Vigilmon alert at 21 days gives you a 21-day window before a customer-visible problem, with 9 days of overlap before renewal should have occurred — enough time to investigate and manually renew if the automated renewal has failed.

Step 6: Set Up Alert Channels

Route Cachet monitoring alerts based on the operational impact of each failure:

1. Go to Alert Channels in Vigilmon.
2. Add PagerDuty for the /api/v1/ping monitor — this represents a complete Cachet service failure during what is likely an active incident.
3. Add a Slack webhook to #infrastructure-alerts for the queue worker and components API monitors.
4. Add email notification for the SSL certificate monitor — lead time is long, urgency is medium.
5. Set Consecutive failures before alert to 2 for the web UI monitor to absorb brief PHP-FPM restart times.

The key routing decision for Cachet is: status page alerts need to go somewhere completely independent of Cachet itself. Cachet subscriber notifications cannot notify you that Cachet is down. Route Vigilmon alerts to PagerDuty, a Slack webhook, or email — channels that operate independently of your status page infrastructure.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP monitor (web UI) | / + body keyword | Status page serving failure, Nginx backend down | | HTTP monitor (/api/v1/ping) | /api/v1/ping + pong body | Full stack failure including database connectivity | | HTTP monitor (components API) | /api/v1/components | API data layer failure, component data unavailable | | Cron heartbeat (queue worker) | queue:work process | Worker exit, subscriber notification delivery failure | | SSL monitor | status.yourdomain.com | Certificate expiry, renewal failure |

The worst possible time for a status page to fail is during an outage — when customers are already looking for information and your team is heads-down on incident response. Vigilmon's external monitoring ensures Cachet is available and serving correct content independently, so you know immediately if the status page infrastructure fails during an incident and can take corrective action before customers notice.

Start monitoring for free at vigilmon.online.