Monitoring a Self-Hosted CyberChef Instance with Vigilmon

CyberChef — the "Cyber Swiss Army Knife" — is a browser-based tool for encoding, decoding, compressing, and analysing data. Security teams, analysts, and developers increasingly self-host it to keep sensitive data off GCHQ's public instance and inside their own network perimeter. But a self-hosted CyberChef that silently goes down breaks workflows and sends users scrambling back to the public instance, potentially leaking data you meant to keep private. Vigilmon keeps your self-hosted CyberChef visible: UI uptime, static asset load, and SSL certificate health, all monitored externally.

What You'll Set Up

• HTTP uptime monitor for the CyberChef web UI
• Static asset availability check to confirm the app loads correctly
• SSL certificate expiry alerts
• Notification routing for team-wide visibility

Prerequisites

• CyberChef deployed and accessible over HTTP or HTTPS (Docker, nginx, or static file server)
• A free Vigilmon account

Step 1: Monitor the CyberChef Web Interface

CyberChef is a static web application — no server-side processing, no database. The simplest and most effective check is an HTTP uptime probe on the root URL:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your CyberChef URL: https://cyberchef.yourdomain.com.
4. Set Check interval to 2 minutes.
5. Set Expected HTTP status to 200.
6. Click Save.

For internal-only deployments (accessible only on a VPN or private network), deploy a Vigilmon private agent inside the network. The agent runs on a machine with access to the internal URL and forwards results to Vigilmon's dashboard.

Step 2: Validate the Main Application Asset

A 200 on the root URL confirms the web server is responding, but CyberChef's actual UI depends on loading CyberChef_v*.min.js — the bundled application. If that file is missing (e.g. a botched deployment that replaced the directory), users get a blank page with no error message.

Add a monitor targeting the main JS bundle directly:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://cyberchef.yourdomain.com/CyberChef_v10.19.0.min.js (adjust the version to match your deployment).
3. Check interval: 5 minutes.
4. Expected HTTP status: 200.
5. Under Advanced, set Expected response body contains to CyberChef (the bundle includes the name in its source header).
6. Click Save.

To find the exact filename your instance serves:

# If running via Docker
docker exec cyberchef ls /usr/share/nginx/html/ | grep -E "CyberChef.*\.js"

# Or check from the browser's network tab when loading the UI

When you update CyberChef to a new version, remember to update this monitor's URL to the new bundle filename.

Step 3: Check the Index Page Renders Correctly

An additional body-content check on the root URL confirms the server isn't returning a generic nginx error page or an empty response dressed as a 200:

1. Open the root URL monitor created in Step 1.
2. Under Advanced, set Expected response body contains to CyberChef.
3. Set Expected response body must NOT contain to 502 Bad Gateway and nginx error.
4. Click Save.

This catches misconfigured proxies that return a 200 status code with an error body — a common failure mode when docker-compose brings services up in the wrong order.

Step 4: SSL Certificate Alerts

Self-hosted CyberChef often handles sensitive data: API keys, encoded tokens, encrypted payloads. An expired TLS certificate will either block access entirely (if HSTS is set) or push users back to public instances. Add certificate monitoring:

1. Open the web UI monitor (Step 1).
2. Enable Monitor SSL certificate.
3. Set Alert when certificate expires in less than 21 days.
4. Click Save.

If CyberChef is behind a Caddy reverse proxy, certificate renewal is automatic but can still fail silently if port 80 is blocked or DNS propagation is slow. The Vigilmon alert gives you advance notice to check:

# Check Caddy's certificate status
caddy adapt --config /etc/caddy/Caddyfile 2>&1 | grep -i certificate

# Or inspect the cert directly
echo | openssl s_client -connect cyberchef.yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

Step 5: Notification Routing for Teams

If multiple people on your team use the self-hosted CyberChef instance, a downtime incident affects everyone. Route Vigilmon alerts to a shared channel:

1. Open each CyberChef monitor → Notifications.
2. Set Alert after 2 failed checks to avoid alerting on a single transient blip.
3. Add a Slack integration pointing to your team's #tools-alerts channel, or configure email to a team distribution list.
4. Set up a Recovery notification so the team knows when the instance is back up — this prevents people from continuing to work around the outage after it's resolved.

For a critical security team tool, consider adding an escalation path: if the instance is down for more than 10 minutes during business hours, a second alert fires to on-call rotation.

Keeping the Instance Updated

CyberChef releases new versions regularly. After each update, verify your asset monitor URL still matches the new bundle filename — the version number is embedded in the filename, so a version bump will change it. Build this check into your update runbook:

# After updating CyberChef
docker pull ghcr.io/gchq/cyberchef:latest
docker-compose up -d cyberchef
# Then update the asset monitor URL in Vigilmon to match the new version

What You've Built

Vigilmon now watches your self-hosted CyberChef instance from the outside: HTTP availability, correct app asset loading, SSL certificate health, and team-wide alert routing. Your secure, self-hosted alternative to the public instance has the reliability layer it needs to stay trustworthy.

Get started at vigilmon.online.