tutorial

The Complete Kubernetes Monitoring Guide 2026

"A comprehensive guide to monitoring Kubernetes clusters in 2026 — control plane, nodes, pods, services, and ingress — plus how external uptime monitoring with Vigilmon complements Prometheus and Grafana."

The Complete Kubernetes Monitoring Guide 2026

Kubernetes gives you orchestration superpowers: self-healing pods, rolling deployments, horizontal autoscaling. But those same capabilities make it easy to think your cluster is healthy when users are quietly experiencing outages. A pod can be Running and Ready while the LoadBalancer IP is unreachable. A CronJob can fail silently for days. A certificate can expire while your internal dashboards show green.

This guide covers what to monitor in a Kubernetes cluster in 2026 — at every layer, from the control plane to individual containers — and how external uptime monitoring with Vigilmon completes the picture that Prometheus and Grafana cannot provide on their own.

The Kubernetes Monitoring Stack: An Overview

Modern Kubernetes monitoring is typically built around three layers:

Internal cluster metrics — Prometheus scraping kube-state-metrics, node-exporter, and the kubelet metrics API. Grafana dashboards, alerting rules, and AlertManager routing. This stack is excellent for resource utilization, pod lifecycle events, and internal error rates.

Application-level observability — Distributed tracing (Jaeger, Tempo), log aggregation (Loki, ELK), and custom business metrics emitted by your services.

External uptime monitoring — HTTP/HTTPS checks from outside the cluster, verifying that public endpoints are reachable, that SSL certificates are valid, and that response times meet SLOs from the user's perspective. This is the gap Vigilmon fills.

All three layers are necessary. An engineering team running only Prometheus and Grafana is monitoring the cluster from the inside. They will miss failures that live at the boundary between the cluster and the public internet.

What to Monitor in Your Kubernetes Cluster

1. Control Plane Health

The control plane (API server, etcd, scheduler, controller manager) is the brain of the cluster. Failures here cascade to everything.

API Server: Monitor latency and error rates on kube-apiserver requests. A slow API server delays pod scheduling and causes cascading timeouts in controllers. Prometheus metrics: apiserver_request_duration_seconds, apiserver_request_total.

etcd: Monitor write latency, leader health, and disk I/O. etcd is a consensus system — if disk latency spikes, leader elections slow down, and the API server stalls. Prometheus metrics: etcd_disk_wal_fsync_duration_seconds, etcd_server_leader_changes_seen_total.

Scheduler and Controller Manager: These are stateless and restart cleanly, but monitor that they are running and that the scheduler has no large backlog of unscheduled pods. Metric: scheduler_pending_pods.

For managed clusters (EKS, GKE, AKS), the control plane is your cloud provider's responsibility, but you should still monitor for API server errors from the client perspective.

2. Node Health

Nodes are the physical or virtual machines running your workloads. Node failures are rarely instantaneous — they degrade.

Resource pressure: Monitor CPU, memory, and disk utilization. When a node hits memory pressure, the kubelet starts evicting pods. When it hits disk pressure, image pulls fail. Metrics: node_memory_MemAvailable_bytes, node_filesystem_avail_bytes.

Node conditions: Prometheus and kube-state-metrics expose kube_node_status_condition for conditions like MemoryPressure, DiskPressure, PIDPressure, and Ready. Alert when any node is NotReady for more than 2 minutes.

Node count: Alert when the number of ready nodes drops below your minimum for the workload profile.

3. Pod and Workload Health

CrashLoopBackOff and restart storms: A pod in CrashLoopBackOff is the most common Kubernetes fire drill. Detect it early: kube_pod_container_status_restarts_total increasing rapidly signals a crash loop.

Pod scheduling failures: Pods stuck in Pending state indicate insufficient resources, affinity/taint mismatches, or PVC provisioning failures. Monitor kube_pod_status_phase{phase="Pending"}.

Deployment rollout health: After every deployment, verify the rollout completes within an expected window. kube_deployment_status_replicas_unavailable going nonzero after a deploy and staying there is a red flag.

HPA and scaling: If you use HorizontalPodAutoscaler, monitor that autoscaling events are occurring when expected. An HPA configured but not scaling under load indicates a metrics pipeline problem.

CronJobs: Kubernetes CronJobs fail silently. If a job fails, it does not restart in the way a Deployment does. Use Vigilmon's heartbeat monitoring (cron monitoring) to verify that scheduled jobs complete on time. Configure your job to send a heartbeat to Vigilmon at the end of a successful run. If the heartbeat does not arrive on schedule, Vigilmon alerts you.

4. Service and Network Health

Service endpoints: A Service with no ready endpoints serves no traffic. Monitor kube_endpoint_address_available and kube_endpoint_address_not_ready.

DNS resolution: CoreDNS failures break service discovery inside the cluster. Monitor coredns_dns_requests_total and coredns_panics_total. A spike in DNS errors or NXDOMAIN responses indicates a CoreDNS problem.

NetworkPolicy: Policy misconfigurations silently drop traffic. This is impossible to monitor directly — the correct approach is external endpoint monitoring (covered below) which detects the user-visible effect.

5. Ingress and External Access

This is where internal monitoring reaches its limits. The Ingress controller (nginx-ingress, Traefik, AWS ALB Ingress) terminates external traffic and routes it to backend Services. Many failure modes here are invisible to internal probes:

  • The Ingress controller pod is healthy, but its configuration reload failed silently
  • Path-based routing rules have a conflict causing some routes to 404
  • The external LoadBalancer IP was accidentally deleted
  • SSL certificate renewal failed; the certificate expired without alerting

Prometheus can monitor the Ingress controller's internal metrics — request rate, error rate, response latency per backend. But it cannot tell you whether https://api.yourcompany.com is actually reachable from Berlin, São Paulo, or Singapore.

How Vigilmon Complements Prometheus and Grafana

Vigilmon is external uptime monitoring — it probes your public endpoints from multiple geographically distributed locations and alerts you when they're unreachable, returning errors, exceeding response time thresholds, or serving expired SSL certificates.

The key difference: Vigilmon sees your service the same way your users do. Prometheus sees your service from inside the cluster. These are fundamentally different vantage points, and you need both.

What Vigilmon Catches That Prometheus Misses

| Failure Mode | Prometheus + Grafana | Vigilmon | |---|---|---| | LoadBalancer IP unreachable | No | Yes | | External DNS failure | No | Yes | | Ingress routing broken (returns 404) | Partial | Yes | | SSL certificate expired | No | Yes | | Response time SLO breach (external) | No | Yes | | CronJob failed silently | No | Yes (heartbeat) | | CDN caching stale error pages | No | Yes | | Regional routing failure | No | Yes (multi-region) |

Vigilmon's Consensus Alerting

Vigilmon requires 3+ geographically distributed monitoring nodes to independently confirm a failure before sending an alert. This eliminates false positives from transient regional packet loss, DNS propagation delays, or brief ISP disruptions — exactly the noise that wakes on-call engineers unnecessarily at 3am.

Practical Setup: Monitoring Your Kubernetes Cluster with Vigilmon

Step 1: Identify Your External Endpoints

List every URL that external users or systems access:

  • https://api.yourdomain.com/health
  • https://app.yourdomain.com
  • https://status.yourdomain.com
  • Any webhook endpoints, OAuth callback URLs, or partner integrations

These are your Vigilmon monitors.

Step 2: Add a Meaningful Health Endpoint

Your Ingress-exposed services should have a /health endpoint that checks real dependencies — database connectivity, cache availability, critical third-party APIs — and returns 200 only when the service can actually serve traffic.

# Example: Kubernetes health check deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
      - name: api
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          periodSeconds: 5

Step 3: Configure Monitors in Vigilmon

  1. Sign up at vigilmon.online — free tier includes 5 monitors with 1-minute check intervals.
  2. Add an HTTP monitor for each external endpoint. Set the expected status code (200) and optionally configure content matching for a known string in the response body.
  3. Set response time thresholds: a latency alert at 2s warns you of degradation before users start complaining.
  4. Configure SSL monitoring: Vigilmon alerts when your certificate will expire in fewer than 14 or 7 days, giving you time to renew before expiry.

Step 4: Set Up CronJob Heartbeat Monitoring

For each Kubernetes CronJob that runs critical business logic, add a heartbeat check in Vigilmon. Configure your job to curl the Vigilmon heartbeat URL on successful completion:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-report
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: reporter
            command:
            - /bin/sh
            - -c
            - |
              python /app/generate_report.py && \
              curl -s https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID

If the job fails before the heartbeat fires, Vigilmon detects the missed heartbeat and alerts.

Step 5: Configure Alert Routing

Vigilmon supports alerts via email, Slack webhooks, and generic webhooks. For Kubernetes environments:

  • Route Slack alerts to your #on-call channel
  • Use the generic webhook integration to push Vigilmon alerts into PagerDuty, OpsGenie, or your incident management tool
  • Set quiet hours for non-critical monitors that should not page overnight

Kubernetes Monitoring Checklist for 2026

Control Plane

  • [ ] API server request latency and error rate
  • [ ] etcd disk write latency
  • [ ] Scheduler pending pod queue length

Nodes

  • [ ] Node Ready condition
  • [ ] CPU, memory, disk pressure
  • [ ] Node count vs. cluster minimum

Pods and Workloads

  • [ ] CrashLoopBackOff detection
  • [ ] Pending pods
  • [ ] Deployment rollout completion
  • [ ] CronJob heartbeat monitoring (Vigilmon)

Services and Networking

  • [ ] Endpoint availability per Service
  • [ ] CoreDNS error rate

Ingress and External

  • [ ] External endpoint uptime (Vigilmon)
  • [ ] SSL certificate expiry monitoring (Vigilmon)
  • [ ] Response time SLOs from external vantage points (Vigilmon)
  • [ ] Multi-region availability (Vigilmon consensus alerting)

Summary

Kubernetes monitoring in 2026 requires multiple layers working together. Prometheus and Grafana give you deep internal visibility into cluster resource utilization, pod health, and application metrics. Vigilmon adds the external perspective — the view your users have — catching failures that internal probes architecturally cannot see.

The combination is not redundant. It is comprehensive. When Prometheus shows all pods healthy and users are reporting errors, Vigilmon is what tells you whether the Ingress is unreachable, the DNS has failed, or the SSL certificate has expired.

Start monitoring your Kubernetes services externally — try Vigilmon free, no credit card required.

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