tutorial

Monitoring Checkly API and E2E Monitoring Platform with Vigilmon: Uptime, API Health & SSL Certificate Alerts

How to monitor your Checkly API monitoring platform with Vigilmon — self-hosted Checkly health checks, API endpoint availability, runner connectivity, and SSL certificate alerts.

How to Monitor Checkly API and E2E Monitoring Platform with Vigilmon

Checkly is the developer-first monitoring platform for API checks and end-to-end browser tests — built on Playwright and running synthetic monitoring jobs on a global infrastructure of distributed check runners. Teams use Checkly to verify that APIs return correct responses, user flows work in real browsers, and production deployments don't break critical paths.

But Checkly's own infrastructure — your self-hosted check runners, the Checkly API, and your monitoring dashboards — needs to be monitored too. External monitoring with Vigilmon provides an independent uptime layer for your Checkly deployment so you know when your monitoring platform itself is unreachable.

Why Checkly needs external monitoring

Even monitoring platforms can go down. These are the failure modes that matter:

  • Self-hosted check runner loses connectivity to Checkly HQ — your internal checks stop running silently; no alerts fire because the runner is the alert-delivery mechanism
  • Checkly API returns 401 for all check runs — API key rotation breaks check ingestion while the platform dashboard stays green
  • Playwright browser binaries become stale after a system update — E2E checks fail at the browser launch stage with zero network visibility from the platform
  • Runner agent process crashes without restarting — checks are scheduled but never executed; the runner host is reachable but the agent process died
  • Checkly dashboard becomes inaccessible — your team can't view check results or triage incidents even though checks are still running
  • Outbound network from the runner is blocked — checks that hit external APIs pass internal connectivity tests but can't reach the target endpoints

External monitoring from Vigilmon verifies that Checkly's endpoints and your check runners are actually operational from an outside perspective.

What you'll need

  • A Checkly account (cloud or self-hosted runner setup)
  • Self-hosted runner endpoints accessible from outside (if using private locations)
  • A free Vigilmon account (sign up takes 30 seconds)

Step 1: Understand Checkly's health endpoints

For self-hosted Checkly check runners (private locations), the runner agent exposes a local health endpoint:

# Check runner health
curl -s -o /dev/null -w "%{http_code}" http://localhost:9090/health

# Check runner metrics (Prometheus-compatible)
curl -s http://localhost:9090/metrics | grep checkly_runner

# Verify runner connectivity to Checkly API
curl -s http://localhost:9090/status | python3 -m json.tool

For self-hosted or on-premise Checkly installations, the API server exposes:

# API health endpoint
curl -s -o /dev/null -w "%{http_code}" https://api.checkly-on-prem.yourdomain.com/health

# Dashboard availability
curl -s -o /dev/null -w "%{http_code}" https://app.checkly-on-prem.yourdomain.com/

Starting a Checkly private location runner with Docker

docker run -d \
  --name checkly-runner \
  -p 9090:9090 \
  -e API_KEY=your-checkly-api-key \
  -e LOCATION_ID=your-private-location-id \
  --restart unless-stopped \
  checkly/agent:latest

Step 2: Create an HTTP monitor for the runner health endpoint

Log in to Vigilmon and create your primary monitor:

  1. Click Monitors → New Monitor
  2. Set the Type to HTTP
  3. Enter your endpoint: https://runner.yourdomain.com/health (or expose the runner health endpoint via reverse proxy)
  4. Set Check interval to 1 minute
  5. Set Expected status to 200
  6. Set Alert after to 1 failure — a dead runner means your checks silently stop running
  7. Click Save

Vigilmon begins checking from multiple geographic regions every minute.

What this monitor catches

| Failure | Vigilmon response | |---------|-----------------| | Runner agent process crashed | Connection refused → alert | | Runner lost connectivity to Checkly HQ | HTTP 503 → alert | | OOM kill of runner process | Connection refused → alert | | Reverse proxy misconfigured | HTTP 502/504 → alert | | Docker container exited | Connection refused → alert | | TLS certificate expired | SSL error → alert |

Step 3: Monitor the Checkly API directly

If you're using Checkly's cloud service, monitor the API endpoint that your check runners and CI pipelines depend on:

  1. Click Monitors → New Monitor
  2. Set the Type to HTTP
  3. Enter: https://api.checklyhq.com/health
  4. Set Expected status: 200
  5. Set Check interval: 2 minutes
  6. Click Save

For on-premise Checkly deployments, replace with your internal API URL. This gives you independent confirmation of whether the Checkly API is reachable from outside your network — separate from what Checkly's own status page reports.

Step 4: Add a TCP monitor for the runner agent port

Monitor the check runner's listening port at the TCP level:

  1. Click Monitors → New Monitor
  2. Set the Type to TCP
  3. Enter: runner.yourdomain.com:9090
  4. Set Check interval: 1 minute
  5. Click Save

TCP-level monitoring detects port binding failures faster than HTTP checks and distinguishes "HTTP handler dead" from "process not listening at all."

Step 5: Monitor the Checkly dashboard

Your team uses the Checkly dashboard to view results and triage incidents. Monitor its availability separately from the check runner:

  1. Click Monitors → New Monitor
  2. Set the Type to HTTP
  3. Enter: https://app.checklyhq.com (cloud) or https://app.checkly-on-prem.yourdomain.com (self-hosted)
  4. Set Expected status: 200
  5. Set Keyword to find: Checkly (or any reliable string from the dashboard HTML)
  6. Set Check interval: 5 minutes
  7. Click Save

A dashboard outage doesn't stop checks from running, but it blocks your team from viewing results and responding to incidents — worth tracking separately.

Step 6: Configure alert channels

Navigate to Alerts → New Alert Channel:

Slack integration:

# In Slack, create an incoming webhook for #monitoring or #checkly-alerts
# In Vigilmon, paste the webhook URL under Alerts → Slack
# Critical: use a DIFFERENT Slack channel than where Checkly sends its own alerts
# — if Checkly is down, you still need a working alert path

PagerDuty / Opsgenie: Use Vigilmon's generic webhook output:

POST https://events.pagerduty.com/v2/enqueue
{
  "routing_key": "YOUR_INTEGRATION_KEY",
  "event_action": "trigger",
  "payload": {
    "summary": "Checkly runner is DOWN — synthetic checks may be silently failing",
    "severity": "critical",
    "source": "vigilmon"
  }
}

Email: Configure direct email alerts as a fallback for when Slack-based alert delivery is itself affected.

Example Vigilmon webhook payload:

{
  "monitor_name": "Checkly Runner /health",
  "status": "down",
  "url": "https://runner.yourdomain.com/health",
  "started_at": "2026-03-10T14:52:00Z",
  "duration_seconds": 240
}

Step 7: Correlate Vigilmon alerts with Checkly runner diagnostics

When an alert fires, run this triage sequence:

# 1. Is the runner agent running?
docker ps | grep checkly-runner
# or for systemd:
systemctl status checkly-agent

# 2. Check runner logs for connectivity or configuration errors
docker logs checkly-runner --tail 100 | grep -E "ERROR|FAIL|disconnect|timeout" -i

# 3. Test the health endpoint directly (bypass proxy)
curl -v http://localhost:9090/health

# 4. Check runner connectivity to Checkly HQ
curl -v https://agent.checklyhq.com/ping

# 5. Verify the runner's API key is still valid
curl -s -H "Authorization: Bearer YOUR_API_KEY" \
  https://api.checklyhq.com/v1/check-groups | python3 -m json.tool

# 6. Check available disk space (Playwright stores screenshots and traces)
df -h | grep -v tmpfs

# 7. Check for zombie Playwright browser processes
ps aux | grep chrome | grep -v grep

Triage decision tree:

  • Runner process not running → check host OOM (dmesg | grep killed), restart agent, investigate memory usage from large Playwright traces
  • Runner running but not picking up checks → API key may have been rotated; verify key in Checkly dashboard under Account → API Keys
  • Checks running but E2E checks failing at browser launch → Playwright binaries may need reinstalling; run npx playwright install chromium inside the runner container
  • Everything works locally but Vigilmon shows down → reverse proxy or firewall rules blocking external access to runner health endpoint

Step 8: Kubernetes deployment for check runners

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkly-runner
  namespace: monitoring
spec:
  replicas: 2
  selector:
    matchLabels:
      app: checkly-runner
  template:
    metadata:
      labels:
        app: checkly-runner
    spec:
      containers:
        - name: checkly-agent
          image: checkly/agent:latest
          env:
            - name: API_KEY
              valueFrom:
                secretKeyRef:
                  name: checkly-secrets
                  key: api-key
            - name: LOCATION_ID
              value: "your-private-location-id"
          ports:
            - containerPort: 9090
          resources:
            requests:
              memory: "512Mi"
              cpu: "250m"
            limits:
              memory: "2Gi"
              cpu: "1000m"
          livenessProbe:
            httpGet:
              path: /health
              port: 9090
            initialDelaySeconds: 30
            periodSeconds: 30
          readinessProbe:
            httpGet:
              path: /health
              port: 9090
            initialDelaySeconds: 10
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: checkly-runner
  namespace: monitoring
spec:
  selector:
    app: checkly-runner
  ports:
    - name: health
      port: 9090
      targetPort: 9090
  type: ClusterIP

Expose the health endpoint via an Ingress and monitor it with Vigilmon — Kubernetes liveness probes tell you what the scheduler sees, Vigilmon tells you what the network sees.

Step 9: Create a status page for your monitoring platform

  1. Go to Status Pages → New Status Page
  2. Name it: "Monitoring Platform Health"
  3. Add your monitors:
    • Checkly Runners: runner health endpoint, TCP port check
    • Checkly API: API health, dashboard availability
  4. Publish internally for:
    • Engineering teams who rely on synthetic check results for incident response
    • On-call engineers who need to know if alerting infrastructure is degraded
    • Leadership tracking monitoring platform SLAs

Putting it all together

| Monitor | Type | What it catches | |---------|------|----------------| | https://runner.yourdomain.com/health | HTTP | Runner availability, agent crashes, connectivity failures | | runner.yourdomain.com:9090 | TCP | Port-level availability | | https://api.checklyhq.com/health | HTTP | Checkly cloud API availability | | https://app.checklyhq.com | HTTP keyword | Dashboard availability for your team |

What's next

  • Alert deduplication — configure Vigilmon to use a different notification channel than Checkly uses; this ensures runner outages don't silently prevent their own alerts from firing
  • SSL certificate monitoring — Vigilmon tracks TLS cert expiry for your runner proxy and on-premise Checkly endpoints automatically
  • Heartbeat monitors — use Vigilmon heartbeats to confirm your CI/CD pipelines are triggering Checkly runs as expected on each deploy

Get started free at vigilmon.online — no credit card, monitors start running in under a minute.

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