Monitoring Fenrus Dashboard with Vigilmon

Fenrus is a personal home server dashboard and startpage that pings your self-hosted services and displays their online/offline status at a glance. It's the front page of your homelab. But who watches the watcher? If Fenrus itself goes down, you lose visibility into every service it monitors. Vigilmon solves this by watching Fenrus from the outside — checking availability, health check execution, configuration persistence, and SSL certificate health so you know when your dashboard needs attention.

What You'll Set Up

HTTP uptime monitor for the Fenrus web interface
Health check scheduler liveness via cron heartbeat
Configuration persistence health (SQLite/JSON read-write)
Weather API and calendar integration endpoint monitoring
User authentication health
SSL certificate expiry alerts

Prerequisites

Fenrus running and accessible (default port 3000)
A free Vigilmon account

Step 1: Monitor the Fenrus Web Interface

Fenrus serves its dashboard UI at the root path. Add a Vigilmon HTTP monitor to confirm the Node.js server is up and responding:

Log in to vigilmon.online and click Add Monitor.
Set Type to HTTP / HTTPS.
Enter your Fenrus URL: https://fenrus.yourdomain.com (or http://your-server-ip:3000 for LAN-only setups).
Set Check interval to 1 minute.
Set Expected HTTP status to 200.
Click Save.

If you expose Fenrus behind a reverse proxy, use the public HTTPS URL so Vigilmon also exercises the proxy layer.

Step 2: Monitor the Fenrus Health Endpoint

Fenrus exposes a health endpoint at /api/health that reports Node.js process status. Create a dedicated monitor for this path:

Click Add Monitor → HTTP / HTTPS.
Set URL to https://fenrus.yourdomain.com/api/health.
Set Expected HTTP status to 200.
Optionally set Response must contain to ok or "status":"ok" to validate the response body.
Set Check interval to 1 minute.
Click Save.

This catches cases where the static UI is cached by a reverse proxy but the Node.js backend has crashed.

Step 3: Heartbeat for the Health Check Scheduler

Fenrus periodically pings every service you've configured and updates their online/offline status on the dashboard. This internal scheduler must keep running for your homelab overview to stay accurate. Use a Vigilmon cron heartbeat to verify the scheduler fires on schedule.

Add a ping to your Fenrus startup or scheduler script:

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

Then create a small companion script that runs on the same server as Fenrus and pings Vigilmon after each health check cycle completes. If you run Fenrus via Docker, add a sidecar health-reporter:

#!/bin/bash
# health-reporter.sh — runs alongside Fenrus, pings Vigilmon every 5 minutes
while true; do
  sleep 300
  # Verify Fenrus health check API is returning updated results
  STATUS=$(curl -sf http://localhost:3000/api/apps | jq length)
  if [ "$STATUS" -gt 0 ]; then
    curl -s https://vigilmon.online/heartbeat/abc123
  fi
done

Run this script as a systemd service or Docker sidecar. If the scheduler stalls, Vigilmon alerts after two missed intervals.

Step 4: Monitor Configuration Persistence

Fenrus stores dashboard configuration — bookmarks, app shortcuts, widget settings — in either a SQLite database or JSON flat files, depending on your deployment. If the storage layer becomes read-only or corrupted, Fenrus may appear to load but silently fail to save changes.

Add a synthetic write-health check:

#!/bin/bash
# config-health.sh — verify Fenrus data directory is writable
DATA_DIR="/path/to/fenrus/data"
TEST_FILE="$DATA_DIR/.vigilmon_write_test"

if touch "$TEST_FILE" 2>/dev/null && rm "$TEST_FILE" 2>/dev/null; then
  curl -s https://vigilmon.online/heartbeat/config-heartbeat-url
else
  echo "Fenrus data directory not writable" >&2
  exit 1
fi

Schedule this with cron every 10 minutes:

*/10 * * * * /opt/fenrus/config-health.sh

Create a matching Vigilmon cron heartbeat with a 15-minute expected interval. If the data directory fills up or loses write permissions, the ping stops and you get alerted before users notice saved configuration silently disappearing.

Step 5: Monitor Weather API Connectivity

Fenrus can display a weather widget by calling an external weather API (OpenWeatherMap or similar). If your server loses outbound internet connectivity or the API key expires, the widget silently fails.

Create a lightweight HTTP monitor from your Vigilmon account that targets the weather API's status endpoint — or test the Fenrus weather proxy if your deployment routes weather requests through Fenrus itself:

Click Add Monitor → HTTP / HTTPS.
Set URL to https://fenrus.yourdomain.com/api/weather (adjust to your Fenrus weather endpoint path).
Set Expected HTTP status to 200.
Set Check interval to 5 minutes.

If your Fenrus deployment proxies weather through its own API, this monitor will catch broken API keys, rate limiting, or outbound network issues from your server.

Step 6: Monitor Calendar Integration

If you've connected Fenrus to an iCal or CalDAV calendar, the calendar widget calls external endpoints on every dashboard load. A stale or inaccessible calendar source causes errors that are invisible to users until they notice the widget showing nothing.

Add a Vigilmon monitor for the calendar source:

Click Add Monitor → HTTP / HTTPS.
Set URL to your CalDAV or iCal source URL (e.g. https://calendar.yourdomain.com/dav/user/calendar).
Set Expected HTTP status to 200 or 207 (WebDAV multi-status).
Set Check interval to 5 minutes.

This catches calendar server downtime independently of Fenrus.

Step 7: Monitor User Authentication

Fenrus supports password protection via an auth middleware. If the auth service breaks, users may be unable to log in even though the dashboard itself is running.

Test the auth flow with a synthetic login probe:

Click Add Monitor → HTTP / HTTPS.
Set URL to https://fenrus.yourdomain.com/api/login (or your Fenrus auth endpoint).
Set Request method to POST.
Set Request body to {"username":"healthcheck","password":"test"}.
Set Expected HTTP status to 401 (a 401 means auth is working — it rejected bad credentials correctly; a 500 means the auth service has crashed).

A working auth service always returns 401 for wrong credentials. A 500 or timeout means the auth middleware has failed.

Step 8: SSL Certificate Expiry Alerts

If Fenrus is exposed over HTTPS via a reverse proxy, certificate expiry will make the dashboard inaccessible to all users. Add a certificate monitor:

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

Twenty-one days gives you enough time to manually renew or debug an auto-renewal failure before users are locked out.

Step 9: Configure Alert Channels

Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
Set Consecutive failures before alert to 2 on the main Fenrus monitor — a single timeout may be a transient network blip.
For the heartbeat monitors (health check scheduler, config persistence), set Consecutive failures to 1 — a missed heartbeat is always meaningful.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Web UI | https://fenrus.yourdomain.com | Node.js crash, reverse proxy failure | | Health API | /api/health | Backend crash behind cached proxy | | Health check scheduler | Heartbeat every 5 min | Scheduler stall, frozen health checks | | Config persistence | Heartbeat every 10 min | Read-only filesystem, disk full | | Weather API | /api/weather | Broken API key, outbound network | | Calendar source | CalDAV/iCal URL | Calendar server down | | Auth middleware | POST /api/login → 401 | Auth service crash | | SSL certificate | Dashboard domain | Let's Encrypt renewal failure |

Fenrus gives your homelab a polished front page — Vigilmon makes sure that front page stays up. With these monitors in place, you'll know about Fenrus problems before your homelab services do, rather than discovering the watcher went down only when you needed it most.