tutorial

Monitoring GoBackup with Vigilmon

GoBackup automates database and file backups — but a silently failing backup job, an unreachable storage backend, or a missed schedule means you discover the gap only when you need to restore. Here's how to monitor every layer with Vigilmon.

GoBackup is an open-source backup tool with a web UI that automates database dumps and file system backups, then uploads them to storage backends like S3, R2, MinIO, Backblaze B2, SFTP, or local disk. It supports PostgreSQL, MySQL, MariaDB, MongoDB, and Redis as backup sources. When you self-host it, you own the reliability of your backup pipeline — and backup tools have a particularly nasty failure mode: they fail silently, and you only discover the gap when you need to restore. Vigilmon gives you HTTP uptime monitoring, TCP port probes, cron heartbeats, and alerting so GoBackup failures surface before a restore is needed.

What You'll Set Up

  • HTTP uptime monitor for the GoBackup web UI (port 2703)
  • Database source connectivity probes (PostgreSQL, MySQL, MongoDB, Redis)
  • Storage backend connectivity check
  • Backup job execution cron heartbeats
  • Backup schedule adherence monitoring (missed backup detection)
  • Notification delivery health check
  • SSL/TLS certificate expiry alert

Prerequisites

  • GoBackup running and reachable over HTTP/HTTPS (default port 2703)
  • At least one backup source and storage backend configured
  • A free Vigilmon account

Step 1: Monitor the GoBackup Web UI

The Go HTTP server hosts the web UI where you can trigger backups manually, view job history, and manage configuration. If it stops responding, you lose operational visibility into your backup pipeline.

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter your GoBackup URL: https://backup.yourdomain.com (or http://your-server-ip:2703 for a direct install).
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Click Save.

A 200 response confirms the Go process is running and the UI is being served. Note that a healthy web UI does not mean backup jobs are running — you need the cron heartbeats in Step 5 for that.

Step 2: Monitor Database Source Connectivity

GoBackup connects to each backup source database to dump its data. If the connection fails, the backup job fails — but silently, unless you have alerting configured. Add a TCP port probe for each database source:

PostgreSQL:

  1. Click Add Monitor → TCP Port.
  2. Host: your PostgreSQL server hostname or IP.
  3. Port: 5432.
  4. Check interval: 1 minute.
  5. Click Save.

MySQL / MariaDB:

Same steps, port 3306.

MongoDB:

Same steps, port 27017.

Redis:

Same steps, port 6379.

These TCP probes confirm the database processes are accepting connections. A connection refused here means GoBackup's next scheduled backup will fail at the dump step — you want to know before the backup window, not after.

Step 3: Monitor Storage Backend Connectivity

GoBackup uploads completed backup archives to a storage backend. If the backend is unreachable, the dump succeeds but the upload fails — leaving you with a completed-looking job and no backup in storage.

S3 / R2 / MinIO (HTTP-based):

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: your S3-compatible endpoint (e.g. https://s3.amazonaws.com or your MinIO URL).
  3. Expected HTTP status: 200, 403, or 405 — any response short of a connection error confirms the endpoint is reachable.
  4. Check interval: 5 minutes.
  5. Click Save.

SFTP backend:

  1. Click Add Monitor → TCP Port.
  2. Host: your SFTP server hostname or IP.
  3. Port: 22.
  4. Check interval: 5 minutes.
  5. Click Save.

Backblaze B2:

Add an HTTP monitor pointing at https://api.backblazeb2.com — a reachable response confirms B2's API is up.

Local disk:

For local disk backends, add a cron heartbeat (see Step 5) that checks available disk space and pings Vigilmon only when sufficient space is available:

#!/bin/bash
AVAIL=$(df /mnt/backup --output=avail | tail -1)
# Alert if less than 10 GB free
if [ "$AVAIL" -gt 10485760 ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_DISK_TOKEN
fi

If the ping goes silent, you have less than 10 GB free and the next backup will fail.

Step 4: Monitor Backup Job API Endpoint

GoBackup exposes an API for triggering and querying backup jobs. Probe it to confirm the backup execution engine is running:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: https://backup.yourdomain.com/api/status (or the health/status endpoint for your GoBackup version — check the API docs or network tab).
  3. Expected HTTP status: 200.
  4. Check interval: 5 minutes.
  5. Click Save.

Step 5: Backup Job Execution Cron Heartbeats

This is the most critical monitor for a backup tool. A heartbeat tells Vigilmon "the backup job ran and completed successfully." If the heartbeat goes silent — because the job errored, the host's cron daemon stopped, or the GoBackup process crashed — Vigilmon alerts you.

Set up one heartbeat per backup job:

In Vigilmon:

  1. Click Add Monitor → Cron Heartbeat.
  2. Set the expected ping interval to match your backup schedule (e.g. 1440 minutes for a daily backup).
  3. Copy the heartbeat URL: https://vigilmon.online/heartbeat/YOUR_TOKEN.
  4. Name the monitor after the job: e.g. GoBackup — PostgreSQL nightly.

In your backup script or wrapper:

If you trigger GoBackup via its CLI (gobackup run --model your_model), wrap it:

#!/bin/bash
gobackup run --model postgresql_production
if [ $? -eq 0 ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_TOKEN
fi

If GoBackup runs on its own schedule, add a post-backup webhook hook in your GoBackup config:

models:
  postgresql_production:
    # ... source and storage config ...
    notification:
      webhook:
        url: https://vigilmon.online/heartbeat/YOUR_TOKEN
        on_success: true
        on_failure: false

The heartbeat only fires on success — a failure leaves it silent, and Vigilmon alerts when the interval expires without a ping.

Step 6: Missed Backup Detection

Set the heartbeat interval in Vigilmon to 10–20% longer than your backup schedule. For example, if you back up daily at 02:00, set the heartbeat interval to 1500 minutes (25 hours) instead of 1440. This gives the backup job a grace window for occasional slow runs without triggering false alerts, while still catching genuinely missed backups.

For weekly backups, set the interval to 7200 minutes (5 days) to account for schedule drift.

Step 7: Backup Completion Notification Delivery

GoBackup can send completion notifications via webhook, SMTP, or Slack. These notifications are distinct from Vigilmon heartbeats — they notify your team via their existing channels. Verify the notification pipeline is working by checking that notifications arrive after a successful backup run.

For webhook notifications, add a Vigilmon HTTP monitor that watches an endpoint you control (e.g. a simple HTTP bin or your own status service) to confirm GoBackup's webhook delivery is reaching external services. If GoBackup's webhook calls start failing, you will only know if you are watching outbound traffic — or if you use the heartbeat approach from Step 5, where silence equals failure.

Step 8: SSL/TLS Certificate Expiry

The GoBackup web UI and API are often accessed by scripts and automation tools. A lapsed certificate breaks these callers without any immediate error message on the UI side.

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

Step 9: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
  2. Set Consecutive failures before alert to 1 on the cron heartbeat monitors — a missed backup heartbeat is always actionable, not noise.
  3. Route database connectivity and heartbeat alerts to a higher-urgency channel — these failures have a direct impact on your recovery point objective (RPO).

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP — web UI | https://backup.yourdomain.com | GoBackup process down, UI unavailable | | TCP — PostgreSQL | :5432 | Database source unreachable | | TCP — MySQL/MariaDB | :3306 | Database source unreachable | | TCP — MongoDB | :27017 | Database source unreachable | | TCP — Redis | :6379 | Database source unreachable | | HTTP — storage backend | S3/MinIO endpoint | Storage unreachable, uploads will fail | | TCP — SFTP backend | :22 | SFTP server unreachable | | HTTP — GoBackup API | /api/status | Backup execution engine down | | Cron heartbeat | per-job post-backup ping | Backup job failure, missed schedule | | SSL certificate | backup domain | TLS renewal failure |

Backup tools fail silently by nature — a successful-looking job with a failed upload leaves you with zero actual backups. With Vigilmon watching every layer from database source connectivity to storage backend reachability to per-job heartbeats, you know about a broken backup pipeline before your next restore attempt, not after.

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