How to Monitor Varnish Cache with Vigilmon (HTTP, TCP, Heartbeat, and SSL Alerts)

Varnish Cache is a high-performance HTTP accelerator used to cache and serve web content at scale. Placed in front of your backend servers, Varnish can serve thousands of requests per second directly from memory — but when Varnish itself goes down or its backend health probes misfire, your entire site can become unreachable with a single point of failure. When that happens, the backend is perfectly healthy but Varnish is silently returning errors to every visitor.

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

Why Varnish needs dedicated monitoring

Varnish introduces its own failure modes that sit upstream of your backend:

Varnish process crash — if the varnishd process dies, requests hit nothing; no backend health probe will catch this because the probe lives inside Varnish itself
VCL compilation failure — after a configuration reload, a VCL syntax error can leave Varnish running the old config or failing to reload entirely, causing stale or incorrect caching behavior silently
Management port (6082) inaccessible — the varnishadm CLI communicates with Varnish over TCP port 6082; if this port becomes unavailable, operational tasks like cache purges and VCL reloads fail with no obvious user-facing symptom
Banned/purged cache serving stale objects — ban or purge automation scripts can fail silently, meaning invalidated content keeps being served to users
Backend health probe drift — Varnish's internal backend health checks can mark backends as sick while the backends are actually healthy (or vice versa), causing Varnish to either pass all traffic to a dead backend or stop serving cached content unnecessarily

External monitoring from Vigilmon, combined with TCP checks on the management port and heartbeats for purge jobs, catches these gaps.

What you'll need

Varnish Cache installed and running (version 6.0 LTS or higher recommended)
Your Varnish HTTP frontend accessible from Vigilmon (public IP or domain)
A free Vigilmon account (sign up takes 30 seconds)

Step 1: Verify your Varnish HTTP frontend

Varnish listens on HTTP by default (port 80 or 6081 in development setups). Before setting up Vigilmon, confirm it's serving requests:

curl -I http://your-varnish-host/

Check the response headers — a healthy Varnish response includes X-Varnish and Via headers:

HTTP/1.1 200 OK
X-Varnish: 12345678
Age: 42
Via: 1.1 varnish (Varnish/7.4)

The Age header tells you the object's cache age in seconds. Age: 0 means a cache miss (request went to backend). A high age means Varnish served it from cache.

Also verify varnishadm connectivity on the management port:

varnishadm -T 127.0.0.1:6082 -S /etc/varnish/secret ping

Expected response: 200 19 PONG ...

Step 2: Add a health-check route to your VCL

Add a dedicated health check path to your VCL so Vigilmon always gets a synthetic 200 response — bypassing backend availability and cache state:

sub vcl_recv {
    # Health check endpoint — synthetic response, no backend hit
    if (req.url == "/varnish-health") {
        return(synth(200, "OK"));
    }
}

sub vcl_synth {
    if (resp.status == 200 && resp.reason == "OK") {
        set resp.http.Content-Type = "text/plain";
        synthetic("varnish-ok");
        return(deliver);
    }
}

Apply the updated VCL:

varnishadm -T 127.0.0.1:6082 -S /etc/varnish/secret vcl.load health_v2 /etc/varnish/default.vcl
varnishadm -T 127.0.0.1:6082 -S /etc/varnish/secret vcl.use health_v2

Test it:

curl http://your-varnish-host/varnish-health
# Expected: varnish-ok

This endpoint answers with a synthetic response generated entirely inside Varnish. If it stops responding, varnishd itself is the problem — not the backend.

Step 3: Set up HTTP monitoring in Vigilmon

Log in to vigilmon.online and go to Monitors → New Monitor
Choose HTTP / HTTPS as the type
Set the URL to: http://your-varnish-host/varnish-health
Set the check interval to 1 minute
Under Expected response:
- Status code: 200
- Response body contains: varnish-ok
Save the monitor

Vigilmon probes Varnish every minute. If varnishd crashes, is OOM-killed, or fails to start after a VCL reload, this monitor fires within a minute.

Step 4: Set up TCP monitoring for the management port

The Varnish management port (TCP 6082) is required for varnishadm operations: cache purges, VCL reloads, backend health checks, and ban operations. If it becomes unreachable, your operational tooling breaks silently.

Monitors → New Monitor → TCP Port
Hostname: your-varnish-host
Port: 6082
Save the monitor

Note: If port 6082 is firewall-restricted to localhost only (recommended for security), set up monitoring from a Vigilmon agent running on the same host, or expose the check through a local health script that writes a status file.

Also add a TCP monitor for the main Varnish HTTP port:

Monitors → New Monitor → TCP Port
Hostname: your-varnish-host
Port: 80 (or 6081 for development)
Save the monitor

Step 5: Set up heartbeat monitoring for ban and purge jobs

If you run automated cache invalidation (ban sweeps, tag-based purges, or content expiry scripts), use heartbeat monitors so Vigilmon alerts you when they stop completing successfully.

How it works: Vigilmon gives you a unique ping URL. Your purge or ban script hits that URL after each successful run.

In Vigilmon, go to Monitors → New Monitor → Heartbeat
Name it (e.g., Varnish nightly ban sweep)
Set the expected interval (e.g., 1 hour for an hourly purge job)
Set a grace period (e.g., 15 minutes)
Copy the ping URL

Add the ping to your purge script:

#!/bin/bash
# Example: purge all objects with a specific tag using varnishadm
varnishadm -T 127.0.0.1:6082 -S /etc/varnish/secret ban "obj.http.X-Cache-Tags ~ product"

if [ $? -eq 0 ]; then
  curl -s "https://vigilmon.online/ping/your-heartbeat-token" > /dev/null
  echo "Ban sweep complete — heartbeat sent"
else
  echo "Ban sweep failed — heartbeat not sent, Vigilmon will alert"
  exit 1
fi

For a systemd timer wrapping a purge script:

# /etc/systemd/system/varnish-ban-sweep.service
[Unit]
Description=Varnish cache ban sweep

[Service]
Type=oneshot
ExecStart=/usr/local/bin/varnish-ban-sweep.sh

# /etc/systemd/system/varnish-ban-sweep.timer
[Unit]
Description=Run Varnish ban sweep hourly

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

If the timer misfires, the varnishadm connection fails, or stale content is being served because bans aren't running, Vigilmon alerts you within the grace period.

Step 6: Enable SSL certificate monitoring

If your Varnish instance sits behind a TLS terminator (Nginx, HAProxy, or Varnish's own SSL support via Hitch), Vigilmon automatically checks SSL certificate expiry for any HTTPS monitor.

Create an HTTPS monitor pointing to your public-facing domain: https://your-domain.example.com/varnish-health
Open that monitor in Vigilmon and go to the SSL tab
Set the Alert before expiry threshold (e.g., 30 days)

Vigilmon alerts you before an expired certificate takes your cached site offline.

Summary: Vigilmon monitors for Varnish Cache

| Monitor | Type | What it catches | |---------|------|-----------------| | /varnish-health (synthetic VCL) | HTTP | Varnish process crash, VCL reload failure | | varnish-host:80 | TCP | HTTP port binding failure, process death | | varnish-host:6082 | TCP | Management port unavailable, varnishadm blocked | | Ban/purge sweep job | Heartbeat | Cache invalidation stopped running | | SSL certificate | SSL | TLS cert expiry before site goes offline |

What's next

Backend health monitoring — add Vigilmon monitors for your origin servers too; that way you know whether an outage is at the Varnish layer or the backend layer
Status page — include your Varnish HTTP monitor in a Vigilmon status page so your team has a single view of caching infrastructure health
Webhook alerts — connect Vigilmon to Slack or PagerDuty so operations teams are notified the instant Varnish becomes unreachable, not when users start complaining about slow or broken pages

Get started free at vigilmon.online — no credit card, monitors start running in under a minute.