Monitoring Komodor with Vigilmon: Agent Health, Watchplane Availability, Webhook Delivery & SSL Certificates

Komodor is the Kubernetes troubleshooting and change intelligence platform that correlates deployments, config changes, and cluster events into a unified timeline so engineering teams can find the root cause of incidents in minutes rather than hours. When the Komodor agent loses connectivity or the watchplane API goes down, your change correlation and alerting pipeline goes dark exactly when you need it most — during an outage. Vigilmon gives you external visibility into Komodor's agent health, watchplane API availability, webhook delivery, and SSL certificates so you know your troubleshooting tooling is operational before your next incident.

What You'll Build

• An HTTP monitor on the Komodor watchplane API health endpoint
• A TCP monitor confirming the Komodor agent egress port is reachable
• Heartbeat monitors verifying webhook delivery and change event ingestion
• SSL certificate monitoring for your Komodor dashboard domain
• Alerting runbook mapped to Komodor failure modes

Prerequisites

• A running Komodor installation with the komodor-agent deployed in your cluster
• Komodor watchplane API accessible (SaaS at app.komodor.com or self-hosted)
• A free account at vigilmon.online

Step 1: Verify the Komodor Watchplane API Availability

Komodor's SaaS watchplane serves the dashboard and webhook ingestion. When it is unreachable, the agent cannot deliver change events and alerts stop firing. The Komodor status page exposes a machine-readable endpoint you can poll:

curl -s https://app.komodor.com/api/v1/health

A healthy watchplane returns a 200 OK response. If you are running a self-hosted Komodor instance, use your internal watchplane URL instead.

Step 2: Create a Vigilmon HTTP Monitor for the Komodor Watchplane

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://app.komodor.com/api/v1/health (or your self-hosted URL).
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Label: Komodor Watchplane API.
7. Click Save.

Set alerts after 1 consecutive failure — when the watchplane is down, all Komodor alerting, change correlation, and webhook delivery halts.

Step 3: Monitor the Komodor Agent Egress Connectivity

The komodor-agent DaemonSet pods connect outbound to the Komodor watchplane over HTTPS (port 443). A network policy change, DNS failure, or egress firewall rule can silently break agent-to-watchplane connectivity without crashing the agent pods. Confirm the egress endpoint accepts TCP connections:

1. Add Monitor → TCP.
2. Host: app.komodor.com (or your self-hosted watchplane hostname).
3. Port: 443.
4. Check interval: 2 minutes.
5. Label: Komodor Agent Egress (TCP 443).
6. Click Save.

This is especially useful for self-hosted Komodor where you control the network path and may inadvertently block agent traffic with a new NetworkPolicy or Calico rule.

Step 4: Monitor Komodor Agent Health via a Heartbeat

The most direct signal that the Komodor agent is operational is whether it is actively delivering events to the watchplane. Set up a Kubernetes CronJob that pings Vigilmon only when at least one Komodor agent pod is Running and its last event delivery timestamp is recent:

Step 4a — Create a Heartbeat monitor in Vigilmon:

1. Add Monitor → Heartbeat.
2. Name: Komodor Agent Active.
3. Expected interval: 10 minutes.
4. Grace period: 5 minutes.
5. Copy the generated ping URL (e.g., https://vigilmon.online/ping/abc123).

Step 4b — Deploy the CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: komodor-agent-heartbeat
  namespace: komodor
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: komodor
          containers:
            - name: check
              image: bitnami/kubectl:latest
              command:
                - sh
                - -c
                - |
                  RUNNING=$(kubectl get pods -n komodor \
                    -l app.kubernetes.io/name=komodor-agent \
                    --field-selector=status.phase=Running \
                    -o name | wc -l)
                  if [ "$RUNNING" -gt "0" ]; then
                    curl -fsS -m 10 https://vigilmon.online/ping/abc123
                  fi
          restartPolicy: OnFailure

If all agent pods are down or evicted, the CronJob stops pinging Vigilmon and an alert fires after the grace period.

Step 5: Monitor Webhook Delivery with a Heartbeat

Komodor can deliver change events and alerts to external systems via webhooks. A webhook delivery failure means your PagerDuty, Slack, or OpsGenie integrations stop receiving Komodor alerts. Verify webhooks are flowing end-to-end using a dedicated heartbeat:

Step 5a — Create a Heartbeat monitor in Vigilmon:

1. Add Monitor → Heartbeat.
2. Name: Komodor Webhook Delivery.
3. Expected interval: 1 hour.
4. Grace period: 20 minutes.
5. Copy the ping URL.

Step 5b — Configure Komodor to call Vigilmon as a webhook target:

In Komodor under Settings → Integrations → Webhooks, add a new webhook:

• URL: https://vigilmon.online/ping/<your-heartbeat-id>
• Events: select a high-frequency event type (e.g., Deployment changes, or a synthetic test deployment)
• Method: GET or POST

Each time Komodor fires a webhook to Vigilmon, the heartbeat resets. If webhook delivery stops for any reason — authentication failure, network outage, or Komodor SaaS incident — the heartbeat expires and Vigilmon alerts you.

Step 6: Monitor the Komodor Dashboard SSL Certificate

The Komodor dashboard is accessed over HTTPS. An expired TLS certificate locks out your engineers from the dashboard, which is the worst possible time to find out — during an incident when you need Komodor's change timeline most:

1. Add Monitor → SSL Certificate.
2. Domain: app.komodor.com (or your self-hosted dashboard domain).
3. Alert when expiry is within: 30 days.
4. Alert again at: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

For self-hosted Komodor behind an internal Ingress, use your internal certificate domain and ensure Vigilmon can reach it.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Watchplane API | Non-200 response | Check Komodor status page; test from agent pod | | Agent egress TCP | Connection refused | Verify NetworkPolicy and egress firewall rules | | Agent heartbeat | No ping within 15 min | kubectl get pods -n komodor; check agent logs | | Webhook heartbeat | No ping within 80 min | Test webhook URL manually; check Komodor webhook logs | | SSL certificate | < 30 days | Renew certificate; verify cert-manager or Ingress TLS config |

Common Komodor Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Komodor SaaS outage | Watchplane HTTP monitor fires within 60 s | | Agent pods evicted or OOMKilled | Agent heartbeat expires after grace period | | NetworkPolicy blocks agent egress | TCP monitor fires; heartbeat stops | | Webhook integration broken | Webhook heartbeat expires | | Dashboard TLS certificate expired | SSL monitor alerts at 30-day threshold | | DNS failure for watchplane hostname | TCP monitor connection fails | | Komodor API rate-limited | HTTP monitor returns non-200 |

Komodor's change intelligence only works when the agent is actively shipping events to the watchplane — a silent agent failure means your next incident starts without the change correlation that would otherwise cut your MTTR from hours to minutes. Vigilmon's layered monitoring of the Komodor watchplane API, agent heartbeat, webhook delivery, and SSL certificates ensures your troubleshooting tooling is verified healthy before you need it.

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