tutorial

Monitoring Rclone with Vigilmon

Rclone syncs data to 70+ cloud providers and is the backbone of countless backup automation pipelines — but a silent sync failure or drifting remote control daemon can go undetected for days. Here's how to monitor Rclone with Vigilmon.

Rclone is the open-source Swiss Army knife for cloud and local storage management, supporting over 70 backend providers including S3, Google Drive, Backblaze B2, Dropbox, SFTP, WebDAV, Azure Blob, and local filesystems. Sysadmins and developers use it for nightly cloud backups, cross-provider sync, remote mounts, and data lifecycle management. Despite being the most widely used open-source storage tool for backup automation, Rclone has no built-in alerting — a failed nightly rclone sync, a stalled remote control daemon, or a broken backend connection can go undetected until data loss becomes apparent. Vigilmon provides heartbeat monitoring for Rclone cron jobs, REST health checks for the remote control daemon, and SSL alerts for HTTPS-proxied Rclone interfaces.

What You'll Set Up

  • Cron heartbeat monitor for Rclone sync/backup jobs (the primary integration — detect missed nightly cloud syncs before data loss)
  • HTTP monitor for the Rclone RCD web interface (port 5572 availability check)
  • REST API monitor for the /rc/noop endpoint (confirming RCD responsiveness)
  • Backend connectivity check via the /operations/about API for configured remotes
  • SSL certificate alerts for HTTPS-proxied Rclone remote control interfaces

Prerequisites

  • Rclone 1.60+ installed with at least one remote configured (rclone config)
  • Rclone cron jobs or a running rclone rcd daemon (optional for Step 3 and 4)
  • A free Vigilmon account

Step 1: Heartbeat Monitoring for Rclone Sync/Backup Jobs

The most critical Rclone monitoring integration is the heartbeat: your Rclone cron job POSTs to a Vigilmon URL after a successful sync. If the job fails, is killed by OOM, or the cron scheduler skips a run, Vigilmon alerts you — before the missed sync becomes a gap in your backups.

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to Cron Heartbeat.
  3. Set Expected ping interval to match your sync schedule (e.g. 1440 minutes for nightly syncs).
  4. Set Grace period to 120 minutes to allow for large transfer windows.
  5. Copy the heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).

Update your backup script to ping Vigilmon only on success:

#!/bin/bash
set -euo pipefail

SOURCE="/home /var/lib/postgresql"
DEST="b2:my-backup-bucket/server-$(hostname)"
VIGILMON_URL="https://vigilmon.online/heartbeat/abc123"

# Run the sync — exits non-zero on failure
rclone sync \
  --transfers 8 \
  --checkers 16 \
  --fast-list \
  --log-level INFO \
  --log-file /var/log/rclone/backup.log \
  $SOURCE "$DEST"

# Only reached on successful exit
curl -fsS --retry 3 "$VIGILMON_URL" > /dev/null

For cron-based automation, add to /etc/cron.d/rclone-backup:

0 2 * * * root /usr/local/bin/rclone-backup.sh 2>&1 | logger -t rclone-backup

The set -euo pipefail flag ensures any rclone error aborts the script before reaching the curl heartbeat call. Vigilmon detects the missing ping and alerts after the grace period.

Step 2: Monitor Multiple Rclone Destinations

If you sync to multiple cloud providers, create a separate Vigilmon heartbeat per destination. Wrap each sync + ping in a function:

#!/bin/bash
set -euo pipefail

SOURCE="/var/backups"
VIGILMON_BASE="https://vigilmon.online/heartbeat"

sync_and_ping() {
  local dest="$1"
  local heartbeat="$2"
  rclone sync "$SOURCE" "$dest" --fast-list --log-level ERROR
  curl -fsS "$heartbeat" > /dev/null
}

# Each destination monitored independently
sync_and_ping "b2:backup-bucket/server" "$VIGILMON_BASE/abc123"
sync_and_ping "gdrive:backup-folder/server" "$VIGILMON_BASE/def456"
sync_and_ping "s3:my-bucket/server" "$VIGILMON_BASE/ghi789"

This way, a failure in the B2 sync alerts on the B2 heartbeat monitor without masking a successful Google Drive sync.

Step 3: HTTP Monitor for the Rclone RCD Web Interface

rclone rcd --rc-web-gui starts Rclone's built-in remote control daemon and web GUI on port 5572. Teams use the RCD daemon for dynamic job management, live transfer monitoring, and programmatic control via the REST API. Add an HTTP monitor to detect when the daemon goes down:

  1. In Vigilmon, click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter: http://your-server:5572/.
  4. Set Check interval to 5 minutes.
  5. Set Expected HTTP status to 200.
  6. Click Save.

Start the RCD daemon with authentication and bind it to localhost (reverse-proxy to HTTPS for production):

rclone rcd \
  --rc-web-gui \
  --rc-addr 127.0.0.1:5572 \
  --rc-user admin \
  --rc-pass "$(openssl rand -hex 16)" \
  --rc-web-gui-no-open-browser \
  --log-file /var/log/rclone/rcd.log \
  --log-level INFO &

For production, use a systemd service to keep the daemon running:

[Unit]
Description=Rclone Remote Control Daemon
After=network.target

[Service]
ExecStart=/usr/bin/rclone rcd --rc-web-gui --rc-addr 127.0.0.1:5572
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Step 4: REST API Monitor for /rc/noop Endpoint

The /rc/noop endpoint is Rclone's purpose-built health check — it accepts any parameters and returns an empty JSON object {} with status 200 if the RCD is running and responsive. Use it as the primary API health monitor rather than the web UI root.

  1. In Vigilmon, click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter: http://your-server:5572/rc/noop.
  4. Set Check interval to 5 minutes.
  5. Set Expected HTTP status to 200.
  6. Optionally set Expected response body contains to {}.
  7. Click Save.

You can verify this endpoint manually:

curl -u admin:password http://localhost:5572/rc/noop
# Returns: {}

The /rc/noop check is more reliable than the web GUI root because it exercises the API router directly, independently of whether the web GUI assets are loaded correctly.

Step 5: Backend Connectivity Check via /operations/about

The /operations/about API endpoint queries a configured Rclone remote for quota and usage information. Use it to verify that backend connectivity is live — not just that the RCD daemon is running, but that it can actually reach your cloud provider.

Add a second HTTP monitor in Vigilmon:

  1. Click Add Monitor → HTTP / HTTPS.
  2. Enter: http://your-server:5572/operations/about?fs=b2:my-bucket.
  3. Set Check interval to 30 minutes (less frequent — this hits the cloud API).
  4. Set Expected HTTP status to 200.
  5. Optionally set Expected response body contains to total (present in all valid quota responses).
  6. Click Save.

The API returns usage data like:

{
  "total": 107374182400,
  "used": 52428800,
  "free": 107321753600
}

A non-200 response indicates an authentication failure, rate limit, or provider-side outage — giving you early warning before a backup attempt fails.

Replace b2:my-bucket with your configured remote and path. Add one monitor per critical remote.

Step 6: SSL Certificate Alerts for HTTPS-Proxied RCD

In production, rclone rcd should be reverse-proxied with HTTPS. An expired certificate blocks web UI access and API calls from any client using TLS verification (which is the correct default).

  1. If you're monitoring the HTTPS proxy URL from Steps 3–5, open that monitor.
  2. Enable Monitor SSL certificate under the SSL section.
  3. Set Alert when certificate expires in less than 21 days.
  4. Click Save.

A minimal nginx proxy for the Rclone RCD:

server {
    listen 443 ssl;
    server_name rclone.example.com;

    ssl_certificate /etc/letsencrypt/live/rclone.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/rclone.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5572;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        # Pass auth headers through
        proxy_pass_header Authorization;
    }
}

Monitor https://rclone.example.com/rc/noop for the API health check with SSL monitoring enabled — this single monitor covers both API availability and certificate validity.

Step 7: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add email, Slack, PagerDuty, or a webhook.
  2. For sync heartbeat monitors (Steps 1–2), set consecutive failures before alert to 1 — a missed backup sync always warrants immediate notification.
  3. For RCD HTTP and TCP monitors (Steps 3–4), set consecutive failures to 2 to tolerate brief daemon restarts.
  4. For backend connectivity monitors (Step 5), set consecutive failures to 3 — cloud providers have transient API hiccups that resolve in minutes.
  5. Add a Maintenance window in Vigilmon during planned Rclone upgrades or remote reconfiguration.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Cron heartbeat | Sync job URL (per destination) | Failed sync, missed schedule, OOM kill | | HTTP uptime | http://server:5572/ | RCD daemon down, web GUI unavailable | | API health | http://server:5572/rc/noop | API router failure, RCD unresponsive | | Backend check | /operations/about?fs=<remote> | Auth failure, provider outage | | SSL certificate | HTTPS proxy domain | TLS certificate expiry |

Rclone's versatility across 70+ backends makes it indispensable for cloud backup automation — but the same flexibility means failures can be silent and provider-specific. With Vigilmon heartbeats watching every sync job, REST health checks confirming RCD availability, and backend connectivity monitors catching auth failures early, you get full-pipeline visibility across every Rclone destination before a missed sync becomes a data loss event.

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