tutorial

Uptime monitoring for Checkmk IT infrastructure monitoring platform

Checkmk is trusted by thousands of enterprises to monitor their entire IT infrastructure — servers, network devices, cloud services, containers, and applicat...

Checkmk is trusted by thousands of enterprises to monitor their entire IT infrastructure — servers, network devices, cloud services, containers, and applications. It does the monitoring so your teams don't have to worry about it. But when Checkmk itself goes down, you lose monitoring coverage across your entire estate simultaneously. Your monitoring platform needs its own monitor.

This tutorial covers production-grade uptime monitoring for Checkmk using Vigilmon. We will walk through:

  • Monitoring the Checkmk web UI availability
  • Monitoring the REST API health endpoint
  • Monitoring the site status page
  • SSL certificate monitoring for HTTPS
  • Heartbeat monitoring for Checkmk scheduled checks and HW/SW inventory
  • Webhook alerts for DOWN/UP events

Prerequisites

  • Checkmk Raw Edition, Cloud Edition, or Enterprise Edition running (version 2.0 or later)
  • A running site (e.g., mysite) accessible at your Checkmk URL
  • A free account at vigilmon.online

Part 1: Verify the Checkmk health endpoints

Checkmk exposes several URLs suitable for external health monitoring:

Web UI (/mysite/check_mk/) — the main Checkmk UI. A 200 response with a redirect to the login page confirms Apache and the Checkmk web layer are operational.

REST API version endpoint (/mysite/check_mk/api/1.0/version) — returns JSON with the Checkmk version and edition. This endpoint requires authentication but returns a structured 401 (not a 5xx) when credentials are missing, making it a reliable backend health indicator.

OMD sites status (/omd/sites/) — lists all configured Checkmk sites and their status. Available without authentication and confirms the OMD layer is running.

# Test the web UI
curl -o /dev/null -w "%{http_code}" https://checkmk.example.com/mysite/check_mk/

# Test the REST API (expects 401 when unauthenticated — means it's working)
curl -o /dev/null -w "%{http_code}" https://checkmk.example.com/mysite/check_mk/api/1.0/version

# Test OMD sites page
curl -o /dev/null -w "%{http_code}" https://checkmk.example.com/omd/sites/

Part 2: Monitor the Checkmk web UI

  1. Log in to vigilmon.online and click Add Monitor.
  2. Choose HTTP(S) monitor.
  3. Enter: https://checkmk.example.com/mysite/check_mk/
  4. Set interval to 1 minute.
  5. Add a keyword check: must contain Checkmk (present in the page title and login form).
  6. Add your alert channel.
  7. Click Save.

The keyword check ensures you catch reverse proxy errors that return 200 with a generic error page rather than the actual Checkmk login.

Part 3: Monitor the REST API health endpoint

The REST API health endpoint (/api/1.0/version) exercises the full Checkmk backend stack — Apache, mod_wsgi, the Checkmk application server, and configuration layer.

  1. In Vigilmon, click Add Monitor.
  2. Choose HTTP(S) monitor.
  3. Enter: https://checkmk.example.com/mysite/check_mk/api/1.0/version
  4. Set interval to 2 minutes.
  5. Set accepted status codes to include 401 (a 401 here means the API is alive and responding correctly to unauthenticated requests).
  6. Add your alert channel.
  7. Click Save.

To monitor the version endpoint with actual content verification, create an automation user in Checkmk (Setup → Users → Add user → Automation user) and add the Authorization header:

Authorization: Bearer cmkautomation yourautomationsecret

Then check for "version" in the response body. This gives you a deeper health signal than a 401 check.

Part 4: Monitor the OMD sites status page

The /omd/sites/ page is served by Apache directly and lists all Checkmk sites and their running status. This is a lightweight check that does not require authentication.

  1. In Vigilmon, click Add Monitor.
  2. Choose HTTP(S) monitor.
  3. Enter: https://checkmk.example.com/omd/sites/
  4. Set interval to 2 minutes.
  5. Add a keyword check: must contain mysite (the name of your Checkmk site, visible in the table).
  6. Add your alert channel.
  7. Click Save.

Part 5: SSL certificate monitoring

Checkmk installations typically use self-signed certificates by default, but production deployments should use certificates from Let's Encrypt or a trusted CA. Certificate expiry monitoring is critical — an expired certificate blocks access to Checkmk for all users and all automation.

  1. In Vigilmon, click Add Monitor.
  2. Choose SSL monitor.
  3. Enter: checkmk.example.com.
  4. Set alert threshold to 14 days before expiry.
  5. Add your alert channel.

Run the SSL monitor alongside the HTTP monitors so a certificate failure triggers a separate, clearly labeled alert.

Part 6: Heartbeat monitoring for scheduled checks

Checkmk's active check scheduler runs service checks at configured intervals. If the cmk --check process hangs, if the Checkmk site stops, or if the check helper pool is exhausted, checks stop running silently. The Checkmk UI may remain reachable while showing stale results.

Heartbeat monitoring catches silent check scheduler failures.

How heartbeat monitoring works

A heartbeat monitor expects a ping from your system at a defined interval. If the ping does not arrive within the grace period, Vigilmon fires an alert. Your Checkmk monitoring wrapper sends the ping at the end of a successful check cycle.

Create a heartbeat monitor for active checks

  1. In Vigilmon, click Add Monitor.
  2. Choose Heartbeat monitor.
  3. Name it Checkmk active check scheduler.
  4. Set interval to 5 minutes.
  5. Set grace period to 3 minutes.
  6. Save and copy the heartbeat URL (format: https://vigilmon.online/ping/hb_xxxxxxxxxx).

Instrument the check scheduler

Create a local check script that runs as part of Checkmk's check cycle and pings the heartbeat URL:

#!/bin/bash
# /usr/local/bin/checkmk-heartbeat.sh
# Deploy as a Checkmk local check: /omd/sites/mysite/local/

HEARTBEAT_URL="https://vigilmon.online/ping/hb_xxxxxxxxxx"
SITE="mysite"

# Verify the site is running
SITE_STATUS=$(omd status "$SITE" 2>&1 | grep -c "running")

if [ "$SITE_STATUS" -gt 0 ]; then
  curl -s "$HEARTBEAT_URL" > /dev/null
  echo "0 Checkmk_heartbeat - OK: Site $SITE running, heartbeat sent"
else
  echo "2 Checkmk_heartbeat - CRIT: Site $SITE not fully running"
fi

Place this script in the local checks directory and make it executable:

cp checkmk-heartbeat.sh /omd/sites/mysite/local/
chmod +x /omd/sites/mysite/local/checkmk-heartbeat.sh

Checkmk executes local checks every check interval. The script both reports a local service result to Checkmk and pings Vigilmon — two monitoring layers from one script.

Create a heartbeat monitor for HW/SW inventory

Checkmk's Hardware/Software Inventory scans run on a longer schedule (typically 4–24 hours). Add a dedicated heartbeat to verify inventory scans are completing:

#!/bin/bash
# /etc/cron.d/checkmk-inventory-heartbeat

# Run after Checkmk inventory scan completes
0 */6 * * *  root  cmk -v --inventory-as-check @all && curl -s "https://vigilmon.online/ping/hb_yyyyyyyyyy" > /dev/null

Part 7: Webhook alerts

Integrate Vigilmon DOWN/UP events with your incident management system:

# Example: Flask webhook receiver
from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route('/webhook/vigilmon', methods=['POST'])
def vigilmon_webhook():
    payload = request.get_json()
    monitor_name = payload.get('monitor_name')
    status = payload.get('status')
    url = payload.get('url')

    if status == 'down':
        print(f'[ALERT] {monitor_name} is DOWN: {url}')
        # Create ServiceNow ticket, page on-call, post to Teams
    elif status == 'up':
        print(f'[RECOVERY] {monitor_name} is back UP: {url}')

    return jsonify({'ok': True})

if __name__ == '__main__':
    app.run(port=5000)

Vigilmon sends this payload structure:

{
  "monitor_id": "mon_abc123",
  "monitor_name": "Checkmk REST API",
  "status": "down",
  "url": "https://checkmk.example.com/mysite/check_mk/api/1.0/version",
  "checked_at": "2026-06-30T09:00:00Z",
  "response_code": 502,
  "response_time_ms": 30012
}

Part 8: Monitor summary table

| Monitor | URL / Target | Type | Interval | |---------|-------------|------|----------| | Checkmk web UI | https://checkmk.example.com/mysite/check_mk/ | HTTP | 1 min | | Checkmk REST API | https://checkmk.example.com/mysite/check_mk/api/1.0/version | HTTP | 2 min | | OMD sites page | https://checkmk.example.com/omd/sites/ | HTTP | 2 min | | SSL certificate | checkmk.example.com | SSL | Daily | | Active check scheduler | heartbeat URL | Heartbeat | 5 min | | HW/SW inventory | heartbeat URL | Heartbeat | 6 hours |

Summary

Your Checkmk deployment now has four layers of monitoring:

  1. Web UI monitor — confirms the Checkmk login page is reachable and serving real content, polled every 60 seconds.
  2. REST API and OMD monitors — exercise the backend stack and catch failures at the application and site management layers.
  3. SSL monitor — alerts you 14 days before your TLS certificate expires.
  4. Heartbeat monitors — verify that the active check scheduler and HW/SW inventory jobs are completing on schedule, catching silent scheduler failures before your monitoring data goes stale.

Vigilmon handles check scheduling, multi-region polling, alert routing, and uptime history. Your Checkmk instance gets its own monitoring coverage — independent of the monitoring it provides to everything else.

Monitor your Checkmk deployment free at vigilmon.online

#checkmk #itmonitoring #devops #monitoring #infrastructure

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