Monitoring Cockpit with Vigilmon

Cockpit is the browser-based Linux system administration interface that ships with RHEL, Fedora, Debian, and Ubuntu — giving you a real-time dashboard for CPU, memory, storage, networking, systemd services, journald logs, containers, and VMs, all without installing additional agents. System administrators and DevOps teams rely on it for day-to-day server management and as a first-response tool during incidents. But if Cockpit itself goes down — whether from a socket unit failure, a crashed service, or an expired TLS certificate blocking browser access — you lose visibility into every server it manages at exactly the moment you need it most. Vigilmon keeps watch on Cockpit's availability, socket health, and certificates so the admin panel is there when you need it.

What You'll Set Up

HTTP monitor for Cockpit web UI availability (port 9090)
TCP probe confirming the cockpit.socket unit is active
Heartbeat monitoring for Cockpit multi-server bridge health
SSL certificate alerts for HTTPS deployments

Prerequisites

Cockpit installed and running (cockpit.socket active via systemd)
Cockpit accessible on port 9090 (default)
A free Vigilmon account

Step 1: Monitor Cockpit Web UI Availability

Cockpit's login page is the primary indicator that the web interface is operational. A successful HTTP response from the login endpoint confirms that the Cockpit service is running and serving requests.

Log in to vigilmon.online and click Add Monitor.
Set Type to HTTP / HTTPS.
Enter the Cockpit URL: https://your-server:9090/cockpit/login
Set Check interval to 1 minute.
Under Keyword monitoring, enable it and set the keyword to Cockpit.
Click Save.

The login page HTML contains the string "Cockpit" in the title and application headers. A keyword match confirms you're getting the actual Cockpit interface, not a generic error page or redirect loop.

If your Cockpit uses a reverse proxy (nginx, Caddy, Traefik) on port 443:

Use https://your-server/cockpit/login as the URL instead.
Set Expected HTTP status to 200.

# Verify the login page responds locally
curl -sk https://localhost:9090/cockpit/login | grep -o "Cockpit"
# Cockpit

Step 2: TCP Probe for Socket Activation Health

Cockpit uses systemd socket activation (cockpit.socket) rather than a persistent daemon. The socket unit keeps port 9090 open and starts the actual Cockpit service on first connection. A TCP probe to port 9090 confirms that the socket unit is active — if the socket unit stops (due to a crash, an admin mistake, or a failed systemd unit dependency), port 9090 closes and incoming connections are refused.

Click Add Monitor → set Type to TCP.
Enter: your-server:9090
Set Check interval to 1 minute.
Click Save.

A refused TCP connection means cockpit.socket is not active. Because socket activation keeps the port open even when the cockpit service itself isn't running (it starts on demand), a TCP failure indicates a deeper problem — the socket unit itself has stopped.

# Check cockpit socket status
systemctl status cockpit.socket
# ● cockpit.socket - Cockpit Web Service Socket
#    Loaded: loaded (/usr/lib/systemd/system/cockpit.socket; enabled)
#    Active: active (listening) since ...

# Restart if needed
systemctl start cockpit.socket

Set Consecutive failures before alert to 1 — a closed port is never transient.

Step 3: Heartbeat for Multi-Server Bridge Health

Cockpit can manage multiple Linux servers from a single primary instance via SSH tunnels (the "cockpit-bridge" mechanism). When you add a secondary server in the Cockpit UI, Cockpit establishes an SSH connection and proxies all management operations through it. If the bridge connection breaks, the secondary server dashboard shows a connection error.

Use a heartbeat script to verify bridge connectivity and alert when a managed server becomes unreachable:

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

Create /usr/local/bin/cockpit-bridge-check.sh on your primary Cockpit server:

#!/bin/bash
HEARTBEAT_URL="https://vigilmon.online/heartbeat/abc123"
MANAGED_SERVERS=("server2.internal" "server3.internal")
ALL_OK=true

for SERVER in "${MANAGED_SERVERS[@]}"; do
  # Test SSH connectivity (Cockpit uses SSH for bridge)
  if ! ssh -o ConnectTimeout=5 -o BatchMode=yes "$SERVER" "echo ok" >/dev/null 2>&1; then
    echo "Cannot reach managed server: $SERVER"
    ALL_OK=false
  fi
done

if $ALL_OK; then
  curl -s "$HEARTBEAT_URL" > /dev/null
fi

chmod +x /usr/local/bin/cockpit-bridge-check.sh

Add to cron:

*/10 * * * * root /usr/local/bin/cockpit-bridge-check.sh

This catches SSH key issues, network routing problems, and managed server downtime before a sysadmin opens Cockpit and finds the secondary server dashboard blank.

Monitor Cockpit Bridge Errors in journald

For a complementary signal, check the systemd journal for Cockpit bridge errors:

# Check for recent bridge errors
journalctl -u cockpit -n 50 --no-pager | grep -i "bridge\|error\|failed"

You can extend the heartbeat script to parse journal output and withhold the ping if bridge errors appear within the last check interval.

Step 4: SSL Certificate Alerts for HTTPS

Cockpit generates a self-signed certificate at install time and places it in /etc/cockpit/ws-certs.d/. Production deployments should replace this with a real certificate (Let's Encrypt via certbot, or an internal CA). Either way, an expired certificate causes browser security warnings that block access for all users.

Add a certificate expiry monitor:

Open the HTTP monitor created in Step 1.
Enable Monitor SSL certificate under the SSL section.
Set Alert when certificate expires in less than 21 days.
Click Save.

Cockpit with Let's Encrypt

If you've configured Cockpit to use a Let's Encrypt certificate (via certbot or acme.sh), add the certificate to Cockpit's trust store:

# Copy the Let's Encrypt certificates to Cockpit
cp /etc/letsencrypt/live/your-domain/fullchain.pem /etc/cockpit/ws-certs.d/1-my-cert.cert
cp /etc/letsencrypt/live/your-domain/privkey.pem /etc/cockpit/ws-certs.d/1-my-cert.key
systemctl restart cockpit

Let's Encrypt certificates expire every 90 days. A 21-day alert window from Vigilmon gives you enough time to investigate and manually trigger renewal if certbot's auto-renewal cron has failed silently:

# Check certificate expiry
openssl s_client -connect localhost:9090 </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate
# notAfter=Apr 15 12:00:00 2026 GMT

# Manually renew if needed
certbot renew --force-renewal
systemctl restart cockpit

Step 5: Configure Alert Channels

Go to Alert Channels in Vigilmon and add Slack, email, PagerDuty, or a webhook.
For the HTTP and TCP monitors, set Consecutive failures before alert to 1 — Cockpit is socket-activated and a failed port means the socket unit is down.
For heartbeat monitors (bridge health), the alert fires automatically when the 10-minute ping interval passes.
Consider adding a Maintenance window around planned system updates:

# During OS updates that restart Cockpit
curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "abc123", "duration_minutes": 10}'

dnf update -y
# Cockpit restarts automatically after package updates

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP keyword | https://host:9090/cockpit/login → "Cockpit" | Service crash, wrong content | | TCP probe | host:9090 | cockpit.socket unit down | | Bridge heartbeat | SSH to managed servers | Multi-server connectivity loss | | SSL certificate | Port 9090 cert expiry | TLS cert expiry blocking access |

Cockpit gives you a fully featured Linux admin panel with zero agents and zero ongoing configuration — but that convenience means its health depends on a handful of systemd units and a TLS certificate staying current. With Vigilmon watching the web interface, socket unit, managed server bridges, and certificate expiry, you can trust that Cockpit will be there the next time you need to diagnose a production issue.