Monitoring OneUptime with Vigilmon

OneUptime is a complete open-source Statuspage.io + PagerDuty alternative: uptime monitoring, public status pages, incident management, on-call scheduling, log ingestion, and distributed tracing — all in a single self-hosted Docker Compose or Kubernetes deployment. When you replace a stack of commercial observability tools with OneUptime, you gain full data ownership and eliminate per-seat SaaS costs, but you also take on operational responsibility for the platform itself. When OneUptime's dashboard service, worker microservices, or probe runners fail, all monitoring coverage silently stops — and your team may not notice until an undetected outage reaches your users. Vigilmon gives you external monitoring for OneUptime's web UI, public status page delivery, internal worker health, probe runner activity, and SSL certificate expiry so OneUptime itself never becomes a single point of failure in your observability stack.

What You'll Set Up

• OneUptime dashboard web UI availability via HTTP monitor
• Public status page endpoint availability and response validation
• OneUptime Worker microservice health via /health/ endpoint
• Probe runner activity via scheduled dashboard availability heartbeat
• SSL certificate expiry alerts for HTTPS OneUptime deployments

Prerequisites

• OneUptime running via Docker Compose or Kubernetes on your server
• Dashboard accessible on port 3009 (default) or via a reverse proxy
• A free Vigilmon account

Step 1: Monitor the OneUptime Dashboard Web UI

The OneUptime dashboard is the primary interface for your engineering team — it shows monitor status, incident timelines, and on-call schedules. Monitor it externally to confirm the web application layer is healthy and serving requests:

1. In Vigilmon, click Add Monitor → HTTP/HTTPS.
2. Enter your OneUptime dashboard URL: http://your-server:3009/ (or https://status.yourdomain.com/ if you use a custom domain).
3. Set Check interval to 2 minutes.
4. Set Expected HTTP status to 200.
5. Under Response body check, add keyword: OneUptime (or any string that appears only in a valid OneUptime login page response).
6. Click Save.

The keyword body check ensures you are not monitoring a reverse proxy error page — if Nginx returns 200 with a "502 Bad Gateway" HTML body because the OneUptime backend is down, Vigilmon catches it.

For Kubernetes deployments where the dashboard is behind an Ingress controller, use the external hostname assigned to the Ingress resource rather than a direct pod or NodePort address.

Step 2: Monitor the Public Status Page Endpoint

OneUptime's public status page is what your end users and customers see during incidents. If the status page itself is down during an outage, customers have nowhere to check service health. Monitor it as a separate monitor from the dashboard — it may run as a different container and can fail independently:

1. In Vigilmon, click Add Monitor → HTTP/HTTPS.
2. Enter the status page URL: http://your-server:3009/status-page/ (or your custom status page domain if configured).
3. Set Check interval to 2 minutes.
4. Set Expected HTTP status to 200.
5. Add a body keyword matching content from your status page (e.g., your company name or a string like All Systems).
6. Click Save.

OneUptime allows multiple status pages under different paths. If you have more than one public status page, add a separate Vigilmon monitor for each — they serve different audiences and can fail independently if per-page resources are unavailable.

To verify the correct URL, access OneUptime's admin dashboard, navigate to Status Pages, and copy the public URL from the settings for each page.

Step 3: Monitor the OneUptime Worker Health Endpoint

OneUptime's architecture splits work across multiple microservices. The Worker service performs the actual uptime checks, processes probe results, and triggers incident creation and notifications. A Worker failure means no uptime checks run, no incidents are created, and no alerts fire — while the dashboard continues to look healthy. Monitor the Worker's internal health endpoint directly:

1. In Vigilmon, click Add Monitor → HTTP/HTTPS.
2. Enter the Worker health URL: http://your-server:3009/health/ (or check your Docker Compose for the worker container's exposed port — it may differ from the dashboard port).
3. Set Check interval to 2 minutes.
4. Set Expected HTTP status to 200.
5. Under Response body check, add: "status": "ok" or healthy depending on your OneUptime version.
6. Click Save.

To find the correct Worker health endpoint for your deployment, check the container configuration:

docker compose ps
docker compose exec worker curl -s http://localhost:3002/health/ 2>/dev/null || \
  docker compose exec worker curl -s http://localhost:8080/health/ 2>/dev/null

The Worker container exposes its health endpoint internally — if your Docker Compose maps it to an external port, use that. If it is internal-only, use the cron heartbeat approach from Step 4 to monitor worker activity from the host.

Step 4: Monitor Probe Runner Health via Cron Heartbeat

OneUptime's Probe Runner service executes the actual connectivity checks for all configured monitors. If the probe runner is down, uptime monitoring silently stops — all monitors show their last-known state without refreshing. A probe runner that appears to run (container is up) but processes no checks is the most dangerous failure mode. Monitor probe runner activity via a scheduled heartbeat:

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set Expected ping interval to 5 minutes.
3. Copy the heartbeat URL (e.g., https://vigilmon.online/heartbeat/abc123).

Create a script that queries the OneUptime API to confirm probes are actively executing checks and pings the Vigilmon heartbeat only when probe activity is confirmed:

#!/bin/bash
# /usr/local/bin/oneuptime-probe-check.sh

ONEUPTIME_URL="http://your-server:3009"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/abc123"
TIMEOUT=20

# Check probe container is running
PROBE_RUNNING=$(docker compose -f /path/to/docker-compose.yml ps probe 2>/dev/null | grep -c "Up" || echo 0)

if [ "$PROBE_RUNNING" -gt 0 ]; then
  # Also verify the probe's internal health endpoint
  HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
    --max-time "$TIMEOUT" \
    "${ONEUPTIME_URL}/health/" 2>/dev/null || echo "000")

  if [ "$HTTP_CODE" = "200" ] || [ "$HTTP_CODE" = "204" ]; then
    echo "OneUptime probe runner healthy: container up, health endpoint OK"
    curl -s "$HEARTBEAT_URL"
  else
    echo "OneUptime probe runner: container up but health endpoint returned HTTP ${HTTP_CODE}"
    exit 1
  fi
else
  echo "OneUptime probe container is not running"
  exit 1
fi

Install as a cron job:

chmod +x /usr/local/bin/oneuptime-probe-check.sh
(crontab -l 2>/dev/null; echo "*/5 * * * * /usr/local/bin/oneuptime-probe-check.sh >> /var/log/oneuptime-probe-check.log 2>&1") | crontab -

This creates a self-monitoring loop: Vigilmon monitors OneUptime's probe runner, so if the probe runner dies, Vigilmon alerts you rather than having monitoring silently stop.

Step 5: SSL Certificate Monitoring for HTTPS OneUptime Deployments

OneUptime deployments behind a reverse proxy (Nginx, Caddy, or Traefik) require TLS certificates for secure dashboard access and API calls. An expired certificate prevents your team from accessing the dashboard and prevents API integrations from submitting telemetry. Set up SSL monitoring:

1. In Vigilmon, click Add Monitor → SSL Certificate.
2. Enter your OneUptime hostname: status.yourdomain.com or your dashboard domain.
3. Set Alert when certificate expires in less than 14 days.
4. Set Check interval to 1 day.
5. Click Save.

If you use separate domains for the dashboard and public status page, add a separate SSL monitor for each domain — both are customer-facing and need valid certificates independently.

For Caddy-managed TLS (which handles ACME renewals automatically), Vigilmon's SSL monitor provides an external verification that Caddy's automatic renewal completed successfully and the renewed certificate is being served correctly to external clients.

Step 6: Set Up Alert Channels

Route OneUptime monitoring alerts based on severity:

1. Go to Alert Channels in Vigilmon.
2. Add a PagerDuty integration for the Worker health and probe runner monitors — these represent complete monitoring failure.
3. Add a Slack webhook to #infrastructure-alerts for the dashboard and status page monitors.
4. Add email notification for the SSL certificate monitor.
5. Set Consecutive failures before alert to 2 for the dashboard monitor to allow for container restart times.

Because OneUptime is itself a monitoring platform, route Vigilmon alerts for OneUptime to a completely independent channel from the ones OneUptime manages — if OneUptime is down, you need to receive alerts via a channel that does not depend on OneUptime being operational.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP monitor (dashboard) | http://your-server:3009/ | Dashboard container crash, Nginx backend failure | | HTTP monitor (status page) | /status-page/ | Status page rendering failure, routing misconfiguration | | HTTP monitor (worker health) | /health/ | Worker microservice crash, background job failure | | Cron heartbeat (probe runner) | Docker container + health check | Probe runner crash, check execution stoppage | | SSL monitor | status.yourdomain.com | Certificate expiry, ACME renewal failure |

OneUptime's consolidation of monitoring, status pages, and incident management into a single deployment is its greatest strength — and its greatest operational risk. When OneUptime is healthy, everything works. When a Worker microservice crashes or the probe runner stops, your entire observability stack is blind. Vigilmon's external monitoring ensures OneUptime itself is watched independently, so a platform failure is detected within minutes rather than discovered during a postmortem.

Start monitoring for free at vigilmon.online.