How to Monitor Your wger Fitness Tracker with Vigilmon

Running wger on your own server means you own the data — but you also own the uptime. A database hiccup, a failed Django migration, or a misconfigured reverse proxy can take your workout tracker offline without any warning. Vigilmon monitors your wger instance from the outside, the same way a user would, and alerts you the moment something breaks.

What You'll Set Up

Vigilmon HTTP monitor for the wger web UI
A second monitor for the wger REST API health endpoint
Response time threshold alerts for slow pages
SSL certificate expiry monitoring

Prerequisites

A running wger instance (Docker or bare-metal, version 2.x)
A free Vigilmon account
Admin access to your wger deployment

Why Monitoring Matters for Self-Hosted wger

wger ships as a Django application backed by PostgreSQL (or SQLite for light installs) with Celery workers handling background tasks like export generation. Self-hosted deployments often sit behind nginx or Caddy. When any layer fails — the database, the worker queue, or the reverse proxy — the web UI stops responding without any noise. If you only notice the outage the next time you try to log a workout, you may have been down for hours.

External monitoring from Vigilmon closes this gap by probing your wger URL from multiple global probes every minute.

Step 1: Monitor the wger Web UI

Log in to vigilmon.online and click Add Monitor.
Set Type to HTTP / HTTPS.
Enter your wger URL — typically https://wger.yourdomain.com.
Set Check interval to 1 minute.
Set Expected status code to 200.
Click Save.

Vigilmon begins probing immediately. Within a minute you'll see the first response time appear on the dashboard.

Step 2: Monitor the wger REST API Health Endpoint

wger exposes a REST API at /api/v2/. A lightweight probe against the API root confirms that Django and the database are responding without requiring authentication:

In Vigilmon, click Add Monitor again.
Set Type to HTTP / HTTPS.
Enter the API status URL: https://wger.yourdomain.com/api/v2/.
Set Expected status code to 200.
Set Expected body contains to "api_version" — the response JSON always contains this key when the API is healthy.
Set Name to something like wger – REST API.
Click Save.

This monitor verifies that the Django application server can reach the database and serve API responses — a deeper check than the homepage alone.

Step 3: Add a Custom Health Endpoint (Optional but Recommended)

If you want a purpose-built health endpoint that checks database connectivity explicitly, add a small Django view. Create custom_health.py in your wger app directory:

# wger/core/views/health.py
from django.http import JsonResponse
from django.db import connection


def health_check(request):
    checks = {}
    status = "ok"

    # Database connectivity
    try:
        with connection.cursor() as cursor:
            cursor.execute("SELECT 1")
        checks["database"] = "ok"
    except Exception as exc:
        checks["database"] = str(exc)
        status = "degraded"

    http_status = 200 if status == "ok" else 503
    return JsonResponse({"status": status, "checks": checks}, status=http_status)

# wger/urls.py  (add to urlpatterns)
from wger.core.views.health import health_check

urlpatterns = [
    ...
    path("health/", health_check, name="health"),
]

After deploying, verify it at https://wger.yourdomain.com/health/:

{
  "status": "ok",
  "checks": {
    "database": "ok"
  }
}

Add a third Vigilmon monitor pointing to /health/ with Expected body contains set to "status":"ok".

Step 4: Configure Response Time Alerts

wger pages that load workout logs or generate charts involve multiple database queries. If the database starts slowing down, pages become sluggish before they become unavailable.

Open any wger monitor in Vigilmon and click Settings.
Find Response time threshold.
Set Warn to 1000ms and Critical to 3000ms.
Save.

You'll receive a warning alert before users start experiencing noticeable slowness.

Step 5: Enable SSL Certificate Monitoring

A wger instance served over HTTPS with an expired certificate locks out all users. Vigilmon checks your certificate's expiry automatically when you monitor an HTTPS URL.

Open your primary wger monitor in Vigilmon.
Scroll to SSL Certificate settings.
Enable Alert when certificate expires within 14 days.
Save.

Vigilmon will send an alert two weeks before expiry — enough time to renew via Let's Encrypt or your certificate provider.

Step 6: Set Up Alert Notifications

Wire up alerts so you hear about problems immediately:

In Vigilmon, go to Alert Channels → Add Channel.
Choose Email, Slack webhook, or another integration.
For Slack, paste your incoming webhook URL and set the payload:

{
  "text": "🏋️ *{{monitor_name}}* is {{status}}!\nURL: {{url}}\nTime: {{timestamp}}"
}

Attach the channel to all your wger monitors under Monitor Settings → Alert Channels.

Step 7: Verify the Full Setup

Temporarily point one of your monitors at a non-existent path (e.g. /vigilmon-test-404) and confirm the alert fires.
Restore the correct URL and confirm the recovery notification arrives.
Review the Response Time History chart in Vigilmon to establish a baseline — spikes indicate database pressure or Celery worker lag.

Going Further

Celery worker monitoring: wger uses Celery for async tasks. If workers stop, exports and background processing silently fail. Add a Vigilmon heartbeat monitor and ping it from a Celery periodic task to verify workers are alive.
Docker health checks: If running wger via Docker Compose, add a healthcheck directive so Vigilmon's findings align with container orchestration restarts.
Status page: Embed a Vigilmon status badge on your wger dashboard or internal wiki so teammates know the current health at a glance.

Your wger deployment is now monitored end-to-end: web UI availability, REST API health, response time thresholds, and SSL certificate expiry — so the only thing you need to track manually is your personal best.