tutorial

Monitoring Nautobot with Vigilmon: Web UI, API Health, Celery Workers, SSL Certificates & Heartbeat Checks

How to monitor Nautobot with Vigilmon — web UI availability, /api/ schema health, /health/ status endpoint, Celery worker availability, SSL certificates, and heartbeat monitoring for scheduled jobs.

Nautobot is the modern open-source Network Source of Truth (NSoT) and network automation platform — the successor to NetBox, backed by Network to Code, and trusted by network engineering teams who treat their network as code. When Nautobot goes down, network automation workflows break, change requests can't be validated against source of truth data, and custom job runs fail silently. When Celery workers stop running, scheduled jobs queue up but never execute — a silent failure that can block provisioning pipelines for hours. Vigilmon gives you external monitoring for Nautobot's web UI, API health endpoint, worker availability, SSL certificates, and scheduled job heartbeats — so you know immediately when your Network Source of Truth is no longer trustworthy.

What You'll Build

  • An HTTP monitor for the Nautobot web UI
  • An HTTP monitor for the /api/ schema health endpoint
  • An HTTP monitor for the /health/ status endpoint
  • SSL certificate monitoring for HTTPS
  • A heartbeat monitor for Nautobot scheduled jobs (change management, data validation, custom runs)

Prerequisites

  • Nautobot installed and accessible via HTTPS (version 2.x recommended)
  • Celery workers running for job execution
  • Redis running as Celery broker
  • A Nautobot API token (generated under Profile → API Tokens)
  • A free account at vigilmon.online

Step 1: Understand Nautobot's Monitoring Surface

Nautobot's key endpoints for external monitoring:

# Web UI availability
curl -I https://nautobot.example.com/

# API schema endpoint (no auth required for schema)
curl -s https://nautobot.example.com/api/ | python3 -m json.tool

# Health check endpoint
curl -s https://nautobot.example.com/health/

# API with authentication
curl -H "Authorization: Token YOUR_API_TOKEN" \
  https://nautobot.example.com/api/dcim/sites/

Nautobot's architecture:

  • Django web process — serves the web UI and API (behind gunicorn/uwsgi)
  • Celery workers — execute Jobs (scheduled, triggered, or queued)
  • Redis — Celery broker and Django cache
  • PostgreSQL — primary database for all Source of Truth data
  • nginx/Apache — reverse proxy in front of gunicorn

Step 2: Create an HTTP Monitor for the Nautobot Web UI

The Nautobot web interface is where your network engineers validate data, run jobs, and view the network source of truth. Monitor it as an external user would:

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://nautobot.example.com/.
  3. Check interval: 2 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: Nautobot (appears in the page title and meta tags of all Nautobot pages).
  7. Label: Nautobot web UI.
  8. Click Save.

This monitor catches:

  • Gunicorn/uwsgi process failures
  • nginx reverse proxy misconfiguration
  • Django application errors preventing page rendering
  • Database connection pool exhaustion that blocks requests
  • Nautobot container/VM restarts

Login redirect: Nautobot redirects unauthenticated requests to /login/. The login page returns 200 and contains Nautobot in the page title — this check works without authentication.

Step 3: Create an HTTP Monitor for the API Schema Endpoint

Nautobot's /api/ endpoint returns the OpenAPI schema root, confirming the Django REST Framework layer is operational. This is a lightweight, unauthenticated check that validates the API stack independently from the web UI:

curl -s https://nautobot.example.com/api/
# Returns JSON with {"swagger":"2.0","info":{"title":"Nautobot","..."}}
# or OpenAPI 3.x schema for newer versions
  1. Add Monitor → HTTP.
  2. URL: https://nautobot.example.com/api/.
  3. Check interval: 2 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: Nautobot (present in the API title field).
  7. Label: Nautobot API schema.
  8. Click Save.

When the API schema monitor fires but the web UI is green, the API layer specifically is degraded — this can indicate DRF configuration issues, authentication backend problems, or middleware failures that affect API but not template-rendered views.

Step 4: Create an HTTP Monitor for the Health Endpoint

Nautobot exposes a /health/ endpoint (standard in Django applications using django-health-check) that validates connectivity to dependent services:

curl -s https://nautobot.example.com/health/
# Returns: {"database_backend":"working","cache_backend":"working",...}
# Or HTTP 200 with OK text for simpler configurations
  1. Add Monitor → HTTP.
  2. URL: https://nautobot.example.com/health/.
  3. Check interval: 1 minute.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Label: Nautobot health endpoint.
  7. Click Save.

Health check content: Nautobot's health endpoint content varies by version and installed plugins. Test with curl first to determine what a healthy response looks like. If it returns a JSON object, add a Keyword like working or ok to catch partial health failures where the endpoint returns 200 but reports degraded components.

The health endpoint is designed for load balancers and orchestrators — it returns non-200 when critical dependencies (database, cache) are unavailable, giving you earlier warning than the web UI monitor alone.

Step 5: Monitor Celery Worker Availability

Nautobot's Jobs (scheduled tasks, change validation runs, custom automation jobs) execute via Celery workers. If Celery workers stop, jobs queue up in Redis but never run — network automation workflows stall without any visible error in the web UI.

Check Worker Health via API

Nautobot provides a worker health API endpoint in newer versions:

# Check Celery worker health (Nautobot 2.x)
curl -H "Authorization: Token YOUR_API_TOKEN" \
  https://nautobot.example.com/api/extras/job-results/?status=running

# Check using Django management command on the server
nautobot-server celery inspect active

Create an HTTP monitor for the jobs API:

  1. Add Monitor → HTTP.
  2. URL: https://nautobot.example.com/api/extras/jobs/.
  3. Check interval: 5 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: count (present in all Nautobot list API responses).
  7. Custom header: Authorization: Token YOUR_API_TOKEN.
  8. Label: Nautobot jobs API.
  9. Click Save.

This confirms the jobs API endpoint is functional — if workers are down, the API still responds, but job results won't update.

Step 6: Add Heartbeat Monitoring for Scheduled Nautobot Jobs

Nautobot scheduled jobs are the most critical automation path in most deployments — data validation runs, IPAM reconciliation, change management checks. Use Vigilmon heartbeats to confirm these jobs are actually completing.

Create a Heartbeat Monitor

  1. Add Monitor → Heartbeat.
  2. Label: Nautobot scheduled data validation.
  3. Expected interval: Match your job schedule (e.g., 60 minutes for hourly jobs).
  4. Grace period: 10 minutes.
  5. Click Save and copy the heartbeat URL.

Instrument Your Nautobot Job

Nautobot Jobs are Python classes. Add a heartbeat ping to your job's run() method:

import requests
from nautobot.extras.jobs import Job

class DataValidationJob(Job):
    class Meta:
        name = "Daily Data Validation"
        description = "Validate IPAM data against network source of truth"

    def run(self):
        # ... your validation logic ...
        self.log_info("Running IPAM validation checks...")
        
        # ... validation complete ...
        
        # Ping Vigilmon heartbeat on successful completion
        try:
            requests.get(
                "https://vigilmon.online/heartbeat/abc123",
                timeout=5
            )
        except Exception:
            self.log_warning("Failed to ping monitoring heartbeat")

For jobs triggered on a schedule, this heartbeat confirms both that the Celery worker executed the job AND that the job completed successfully.

Separate Heartbeats per Job Type

| Job | Vigilmon Label | Interval | |---|---|---| | IPAM reconciliation | Nautobot IPAM reconcile | 24h | | Change validation | Nautobot change validation | 1h | | Device config backup | Nautobot config backup | 24h | | Compliance check | Nautobot compliance | 4h |

Step 7: Monitor SSL Certificates

Nautobot serves its web UI and API over HTTPS. An expired certificate causes:

  • Automation scripts making API calls to fail with TLS errors
  • Network engineers to see browser certificate warnings
  • Webhook integrations to break
# Check certificate expiry
openssl s_client -connect nautobot.example.com:443 2>/dev/null | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: nautobot.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Step 8: Configure Alerting

In Vigilmon under Settings → Notifications, configure alert channels:

| Monitor | Trigger | Action | |---|---|---| | Web UI | Non-200 or keyword missing | systemctl status nautobot; check gunicorn logs | | API schema | Non-200 or keyword missing | Django/DRF issue; check application logs | | Health endpoint | Non-200 | Database or cache connectivity; check Redis and PostgreSQL | | Jobs API | Non-200 | API layer failure; check authentication and DRF config | | Heartbeat (scheduled job) | No ping within window | Check Celery workers: nautobot-server celery inspect active | | SSL certificate | < 30 days | Renew Let's Encrypt cert; reload nginx |

On Celery worker failures: When heartbeat alerts fire, run nautobot-server celery inspect active on the server. If no workers respond, check systemctl status nautobot-celery and Redis connectivity — Celery workers need Redis as their broker.

Common Nautobot Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Gunicorn process crash | Web UI returns 502; API schema fails | | PostgreSQL connection failure | Health endpoint fails; web UI returns 500 errors | | Redis unavailable | Health endpoint fails (cache check); Celery workers can't pick jobs | | Celery worker stopped | Heartbeat misses; jobs queue but never execute | | nginx misconfiguration after upgrade | Web UI returns 502/504; API schema fails | | SSL certificate expires | SSL monitor alerts; API clients get TLS errors | | Django migrations not applied after upgrade | Web UI returns 500 on database queries | | Job failure mid-run | Heartbeat not sent; investigate job result in UI | | LDAP/SSO auth failure | Web UI login returns 500; users can't authenticate | | Disk full on Nautobot host | Log writes fail; app may become unstable |

Nautobot is the single source of truth for your network — when it's degraded, every downstream automation that queries it for device data, IPAM assignments, or configuration templates is working with stale or missing information. Vigilmon monitors the full Nautobot stack externally: the web UI your engineers use, the API your automation scripts call, the health endpoint that validates database and cache connectivity, and the heartbeats that confirm scheduled jobs are actually executing. When Nautobot's truth becomes uncertain, Vigilmon makes certain you know.

Start monitoring Nautobot in under 5 minutes — register free at vigilmon.online.

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