tutorial

Monitoring Anope IRC Services with Vigilmon

Anope provides NickServ, ChanServ, and other critical IRC services — here's how to monitor the Anope daemon, IRCd uplink, MySQL database, and SMTP for registration emails with Vigilmon.

Anope is the services layer that makes a self-hosted IRC network usable: NickServ handles nickname registration, ChanServ manages channel access lists, and OperServ gives IRC operators administrative control. When Anope goes down, users cannot authenticate to registered nicknames, channel modes reset, and the IRC network feels broken even if the IRCd itself is up. Vigilmon monitors the Anope process, database connectivity, and email delivery so you catch failures the moment they happen.

What You'll Set Up

  • Process heartbeat to detect Anope daemon crashes
  • MySQL/MariaDB or PostgreSQL database connectivity check
  • IRCd uplink health via process-level monitoring
  • SMTP connectivity check for registration email delivery
  • Disk space monitoring for Anope data files

Prerequisites

  • Anope installed and running, connected to an IRCd (InspIRCd, UnrealIRCd, or compatible)
  • MySQL, MariaDB, or PostgreSQL running as the Anope database backend
  • A free Vigilmon account

Step 1: Monitor the Anope Daemon Process

Anope does not expose an HTTP server by default — it communicates via the IRC server-to-server protocol. Process heartbeats are the most reliable way to verify the daemon is alive.

  1. In Vigilmon, click Add Monitor → Cron Job / Heartbeat.
  2. Set Expected interval to 5 minutes.
  3. Copy the heartbeat URL.

Create a cron job that pings only when the anope process is running:

# /etc/cron.d/anope-heartbeat
*/5 * * * * anope pgrep -x anope && curl -fsS --retry 3 https://vigilmon.online/ping/your-heartbeat-id > /dev/null 2>&1

If Anope crashes, pgrep fails, the && prevents the curl, and Vigilmon marks the heartbeat as missed and alerts you.

If you run Anope under systemd:

# /etc/systemd/system/anope-heartbeat.service
[Unit]
Description=Anope Vigilmon heartbeat
After=anope.service
BindsTo=anope.service

[Service]
Type=oneshot
User=anope
ExecStart=/usr/bin/curl -fsS --retry 3 https://vigilmon.online/ping/your-heartbeat-id

# /etc/systemd/system/anope-heartbeat.timer
[Unit]
Description=Anope heartbeat every 5 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

systemctl enable --now anope-heartbeat.timer

The systemd unit binds to anope.service, so if Anope stops, the heartbeat service also stops running.

Step 2: Monitor Database Connectivity

Anope stores all nick registrations, channel access lists, memos, and service configuration in a database. If the database becomes unreachable, Anope cannot authenticate users, enforce channel modes, or persist new registrations.

MySQL / MariaDB

Add a heartbeat that pings only when the database accepts connections:

  1. Add a second heartbeat monitor in Vigilmon with Expected interval 5 minutes.
# /etc/cron.d/anope-db-heartbeat
*/5 * * * * anope \
  mysqladmin -h localhost -u anope -p'your-db-password' ping -s && \
  curl -fsS --retry 3 https://vigilmon.online/ping/your-db-heartbeat-id > /dev/null 2>&1

mysqladmin ping returns exit code 0 if the MySQL server is up and accepting connections. Store the password in a .my.cnf file to avoid it appearing in the process list:

# ~/.my.cnf (owned by the anope user, chmod 600)
[client]
user = anope
password = your-db-password

# /etc/cron.d/anope-db-heartbeat
*/5 * * * * anope \
  mysqladmin -h localhost ping -s && \
  curl -fsS --retry 3 https://vigilmon.online/ping/your-db-heartbeat-id > /dev/null 2>&1

PostgreSQL

# /etc/cron.d/anope-db-heartbeat
*/5 * * * * anope \
  pg_isready -h localhost -U anope -d anope -q && \
  curl -fsS --retry 3 https://vigilmon.online/ping/your-db-heartbeat-id > /dev/null 2>&1

Step 3: Monitor IRCd Uplink Connectivity

Anope connects to the IRCd via a server-to-server (S2S) protocol link. If this link drops — due to a network partition, IRCd restart, or misconfigured password — Anope cannot relay service commands and users cannot authenticate.

You cannot probe the S2S link over HTTP, but you can verify the IRCd's client port is accepting connections and check Anope's link status via the Anope log.

Monitor the IRCd's client port:

  1. Add a Vigilmon monitor with Type TCP Port.
  2. Set Host to your IRCd hostname.
  3. Set Port to 6667 (or 6697 for TLS).
  4. Set Check interval to 1 minute.
  5. Click Save.

If the IRCd's client port is closed, the S2S link to Anope is also certainly broken.

Monitor Anope's link status via log heartbeat:

Add a script that checks Anope's log for recent S2S link activity:

#!/bin/bash
# /usr/local/bin/anope-link-check.sh
LOG="/var/log/anope/anope.log"
TIMEOUT_MINUTES=15

# Check if any "Server" (uplink) activity appears in the last N minutes
if find "$LOG" -newer /tmp/anope-link-check-sentinel 2>/dev/null | grep -q . || \
   grep -q "$(date -d "-${TIMEOUT_MINUTES} minutes" +'%Y-%m-%d')" "$LOG" 2>/dev/null; then
  curl -fsS --retry 3 https://vigilmon.online/ping/your-link-heartbeat-id > /dev/null 2>&1
fi
touch /tmp/anope-link-check-sentinel

Step 4: Expose a Simple HTTP Health Endpoint

To give Vigilmon a proper HTTP target for Anope health, run a tiny health check wrapper alongside Anope:

#!/bin/bash
# /usr/local/bin/anope-health-server.sh
# Serves a simple HTTP health endpoint on port 9091

while true; do
  ANOPE_OK=$(pgrep -x anope > /dev/null 2>&1 && echo "ok" || echo "down")
  DB_OK=$(mysqladmin ping -s > /dev/null 2>&1 && echo "ok" || echo "down")

  if [ "$ANOPE_OK" = "ok" ] && [ "$DB_OK" = "ok" ]; then
    STATUS=200
    BODY='{"status":"ok","anope":"ok","db":"ok"}'
  else
    STATUS=503
    BODY="{\"status\":\"degraded\",\"anope\":\"$ANOPE_OK\",\"db\":\"$DB_OK\"}"
  fi

  RESPONSE="HTTP/1.1 $STATUS OK\r\nContent-Type: application/json\r\nContent-Length: ${#BODY}\r\n\r\n$BODY"
  echo -e "$RESPONSE" | nc -l -p 9091 -q 1
done

Or use a simple Python one-liner for a more robust server:

#!/usr/bin/env python3
# /usr/local/bin/anope-health.py
import subprocess, json
from http.server import HTTPServer, BaseHTTPRequestHandler

class Health(BaseHTTPRequestHandler):
    def log_message(self, *args): pass
    def do_GET(self):
        anope = subprocess.run(['pgrep', '-x', 'anope'], capture_output=True)
        db = subprocess.run(['mysqladmin', 'ping', '-s'], capture_output=True)
        ok = anope.returncode == 0 and db.returncode == 0
        body = json.dumps({'status': 'ok' if ok else 'degraded'}).encode()
        self.send_response(200 if ok else 503)
        self.send_header('Content-Type', 'application/json')
        self.end_headers()
        self.wfile.write(body)

HTTPServer(('', 9091), Health).serve_forever()

Run as a systemd service and add a Vigilmon HTTP monitor at http://your-server:9091/ expecting HTTP 200.

Step 5: Monitor SMTP for Registration Emails

If Anope is configured to send email confirmations for new nickname registrations, SMTP availability matters. A broken mail relay means new users cannot confirm their accounts.

Add a TCP port monitor for your SMTP relay:

  1. In Vigilmon, click Add Monitor.
  2. Set Type to TCP Port.
  3. Set Host to your SMTP relay hostname.
  4. Set Port to 587 (submission) or 25 (MTA-to-MTA).
  5. Set Check interval to 5 minutes.
  6. Click Save.

If you use a third-party relay (SendGrid, Mailgun, AWS SES), monitor their status page or add an SMTP check against their submission endpoint.

Step 6: Monitor Disk Space for Anope Data

Anope writes logs and optionally stores memos and backups on disk. A full disk causes Anope to fail to write the database or crash on log rotation.

# /etc/cron.d/anope-disk-heartbeat
*/15 * * * * anope \
  USAGE=$(df /var/lib/anope --output=pcent | tail -1 | tr -d ' %') && \
  [ "$USAGE" -lt 85 ] && \
  curl -fsS --retry 3 https://vigilmon.online/ping/your-disk-heartbeat-id > /dev/null 2>&1

Set the heartbeat interval to 20 minutes — if disk usage exceeds 85%, Vigilmon alerts on a missed heartbeat.

Step 7: Configure Alerts

  1. In Vigilmon, go to Settings → Alerts.
  2. Add your alert channel: Slack, email, or webhook.
  3. Route Anope process heartbeat failures to your highest-priority alert channel — an Anope crash disables authentication for all IRC users.

Recommended alert thresholds:

| Monitor | Alert trigger | Priority | |---|---|---| | Anope daemon heartbeat | 1 missed interval | Critical | | Database heartbeat | 2 missed intervals | Critical | | IRCd TCP port | 1 failure | Critical | | SMTP TCP port | 2 failures | Warning | | Disk space heartbeat | 1 missed interval | Warning |

What to Watch

| Monitor | Check | Interval | |---|---|---| | Anope process | pgrep heartbeat | 5 minutes | | MySQL/PostgreSQL | mysqladmin/pg_isready heartbeat | 5 minutes | | IRCd client port | TCP port check (6667/6697) | 1 minute | | Health HTTP endpoint | HTTP 200 | 1 minute | | SMTP relay | TCP port check (587/25) | 5 minutes | | Disk space | Disk < 85% heartbeat | 15 minutes |

Conclusion

Anope is the invisible backbone of a self-hosted IRC network — and when it fails, the whole network feels broken even if the IRCd stays up. With Vigilmon monitoring the Anope daemon, database connectivity, IRCd port, and SMTP relay, you'll catch failures within minutes instead of discovering them when users report they can't identify to their nicknames.

Sign up for Vigilmon free →

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles