Bugsink Monitoring with Vigilmon: Uptime, Health Checks & Alert Integration

Your error tracker went down at 3 AM. A critical bug started hitting production. Hundreds of events were sent — and none of them arrived. Your team debugged blind for six hours because the very tool designed to catch errors was itself silently broken.

Bugsink is a self-hosted, open-source error tracking platform compatible with the Sentry SDK. It receives error events from your applications, groups them, and notifies your team. But because Bugsink runs on your own infrastructure, it has no external watchdog. If Bugsink goes down, you lose visibility into all your application errors — and you won't know until someone manually notices.

Vigilmon gives Bugsink that external watchdog: uptime checks from multiple global regions, health endpoint monitoring, and alerts to Slack, email, or any webhook before your error pipeline silently breaks.

This tutorial covers monitoring a self-hosted Bugsink instance end-to-end with Vigilmon.

What You'll Build

• A Vigilmon HTTP monitor on Bugsink's health endpoint
• A keyword monitor to detect misconfiguration or startup failures
• A DSN connectivity check to verify event ingestion is reachable
• Alert channels to your team

Prerequisites

• A running Bugsink instance (Docker or bare-metal)
• A free account at vigilmon.online

Step 1: Monitor Bugsink's Health Endpoint

Bugsink exposes a lightweight health check endpoint at /_health/. This endpoint returns HTTP 200 when the application is running and connected to its database. If Bugsink's process crashes, its database becomes unreachable, or its worker queues stall, this endpoint will return a non-200 response or time out.

Test it:

curl -I https://bugs.yourcompany.com/_health/

Expected response:

HTTP/2 200
content-type: text/plain; charset=utf-8

Set up the Vigilmon monitor:

1. Log in to Vigilmon and click New Monitor → HTTP.
2. Set URL to https://bugs.yourcompany.com/_health/.
3. Set Check interval to 60 seconds.
4. Set Expected status code to 200.
5. Save the monitor.

Vigilmon now polls Bugsink's health endpoint every minute from multiple global regions. If the endpoint fails to respond or returns a non-200 status, you receive an alert within minutes.

Step 2: Monitor the Bugsink Web Interface

The /_health/ endpoint confirms the Django application process is alive, but it doesn't verify that Bugsink's web UI is fully functional. Add a second monitor on the login page to catch issues like broken static file serving, misconfigured reverse proxies, or failed migrations that would prevent users from signing in.

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to https://bugs.yourcompany.com/ (or /accounts/login/).
3. Set Expected status code to 200.
4. Under Advanced → Keyword check, configure:
   • Keyword present: "Bugsink" or your instance's title
   • Keyword absent: "502", "503", "Internal Server Error"
5. Save.

This monitor catches cases where the reverse proxy (Nginx or Caddy) is up but Bugsink itself is returning error pages.

Step 3: Verify DSN Event Ingestion Endpoint

The most critical path in Bugsink is the event ingestion API — the endpoint your applications POST error events to. It lives at /api/<project-id>/store/. If this endpoint is down, your error events are silently dropped.

You can monitor the ingestion endpoint directly. A GET request to /api/0/ (Bugsink's API root) should return a valid JSON response:

curl https://bugs.yourcompany.com/api/0/

Expected response:

{"version": "7"}

Set up the monitor:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to https://bugs.yourcompany.com/api/0/.
3. Set Expected status code to 200.
4. Under Advanced → Keyword check:
   • Keyword present: "version"
5. Save.

This confirms that Bugsink's API layer is reachable and responding — the same layer your Sentry-SDK-compatible clients hit when ingesting errors.

Step 4: Monitor SSL Certificate Expiry

Bugsink's DSN uses HTTPS. If your TLS certificate expires, all SDK clients will fail to send error events — and most SDKs fail silently by default.

Vigilmon monitors SSL certificate expiry automatically on any HTTPS monitor. To verify:

1. Open your Bugsink health monitor in Vigilmon.
2. Under SSL, confirm that Certificate expiry alert is enabled.
3. Set the alert threshold to 14 days before expiry.

Vigilmon will alert you two weeks before your certificate expires, giving you time to renew before your error pipeline breaks.

Step 5: Set Up Docker Health Check (Self-Hosted)

If you run Bugsink in Docker, add a health check to your docker-compose.yml so Docker can restart unhealthy containers automatically:

services:
  bugsink:
    image: bugsink/bugsink:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/_health/"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

This Docker health check works in parallel with Vigilmon: Docker restarts unhealthy containers at the infrastructure level, while Vigilmon alerts your team at the external observation level.

Step 6: Alert Channels

Go to Notifications → New Channel in Vigilmon and configure:

• Email — immediate alerts to your on-call engineer or team inbox
• Webhook — post to Slack, Discord, or PagerDuty

A Slack alert for a Bugsink outage looks like:

🔴 DOWN: bugs.yourcompany.com/_health/ (HTTP 502)
Check: Bugsink Health
Region: US-East
Duration: 3 minutes
Triggered: 2026-07-03 03:12 UTC

When Bugsink recovers:

✅ RECOVERED: bugs.yourcompany.com/_health/
Downtime: 8 minutes

Step 7: Status Page

Go to Status Pages → New Status Page in Vigilmon. Add all three Bugsink monitors and publish. Share the URL with your engineering team so everyone has a single place to check Bugsink's operational status during an incident.

What You've Built

| Failure scenario | How Vigilmon catches it | |---|---| | Bugsink process crash | /_health/ returns non-200 or times out | | Database unreachable | /_health/ fails (Django health check tests DB) | | Reverse proxy (Nginx/Caddy) down | Web UI monitor detects 502/504 | | Broken migrations / startup error | Web UI keyword monitor detects error page | | API layer down (events not ingested) | /api/0/ monitor returns non-200 | | TLS certificate expiry | SSL monitor alerts 14 days before expiry | | DNS misconfiguration | HTTP monitors detect DNS resolution failure |

Your error tracker is only as reliable as the infrastructure it runs on. Bugsink is purpose-built to be lean and self-contained — but no self-hosted service can monitor itself. Vigilmon provides the external, independent check that confirms Bugsink is alive and accepting your application's error events.

Start monitoring your Bugsink instance today — register free at vigilmon.online.