How to Monitor cert-manager in Kubernetes

title: "How to Monitor cert-manager in Kubernetes" description: "A practical guide to monitoring cert-manager certificate expiry, ACME challenge failures, renewal loops, and integrating Vigilmon uptime checks for production Kubernetes clusters." date: 2026-07-01 tags: [kubernetes, cert-manager, monitoring, tls, vigilmon]

cert-manager automates TLS certificate provisioning and renewal in Kubernetes. When it silently fails — expired certificates, stalled ACME challenges, renewal loops — your users hit browser certificate errors before your team knows anything is wrong. This guide covers what to monitor, how to alert on it, and how Vigilmon completes the picture.

What Can Go Wrong with cert-manager

cert-manager manages the full certificate lifecycle: requesting, validating, issuing, and renewing. Each phase can fail:

• Certificate expiry — renewal jobs failing silently, leaving an expiring cert in place
• ACME challenge failures — DNS-01 or HTTP-01 validation failing due to misconfigured DNS, firewall rules, or Ingress controller issues
• Renewal loops — cert-manager requesting a new cert every few minutes without ever succeeding
• Webhook unavailability — the cert-manager webhook pod crashing, blocking all new Certificate resource creation

Key Metrics to Monitor

cert-manager exposes a Prometheus metrics endpoint on port 9402 of the controller pod. Scrape it with:

# prometheus scrape config
- job_name: 'cert-manager'
  kubernetes_sd_configs:
    - role: endpoints
      namespaces:
        names: [cert-manager]
  relabel_configs:
    - source_labels: [__meta_kubernetes_service_name]
      action: keep
      regex: cert-manager

Certificate Expiry

# Certificates expiring within 7 days
certmanager_certificate_expiration_timestamp_seconds - time() < 7 * 24 * 3600

# Certificates that are not ready
certmanager_certificate_ready_status{condition="False"} == 1

ACME and Issuance Failures

# Issuance attempts that failed
rate(certmanager_certificate_renewal_errors_total[5m]) > 0

# Controller sync errors (covers ACME challenge controller)
rate(certmanager_controller_sync_error_count[5m]) > 0

Renewal Loops

A renewal loop shows up as a high rate of issuance requests with no certificates transitioning to Ready:

# High renewal request rate with low success rate
rate(certmanager_http_acme_client_request_count[5m]) > 10
and
certmanager_certificate_ready_status{condition="True"} == 0

Alerting with Prometheus + Alertmanager

Add these rules to your PrometheusRule:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: cert-manager-alerts
  namespace: cert-manager
spec:
  groups:
    - name: cert-manager
      rules:
        - alert: CertificateExpiringSoon
          expr: |
            certmanager_certificate_expiration_timestamp_seconds - time() < 7 * 24 * 3600
          for: 1h
          labels:
            severity: warning
          annotations:
            summary: "Certificate {{ $labels.name }} in {{ $labels.namespace }} expires in < 7 days"

        - alert: CertificateNotReady
          expr: certmanager_certificate_ready_status{condition="False"} == 1
          for: 10m
          labels:
            severity: critical
          annotations:
            summary: "Certificate {{ $labels.name }} is not ready in {{ $labels.namespace }}"

        - alert: CertManagerRenewalErrors
          expr: rate(certmanager_certificate_renewal_errors_total[5m]) > 0
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "cert-manager renewal errors detected"

Inspecting Certificate State with kubectl

When an alert fires, dive into the Certificate and CertificateRequest resources:

# Check all certificates and their ready status
kubectl get certificates -A

# Describe a specific certificate to see conditions and events
kubectl describe certificate my-app-tls -n production

# Check the latest CertificateRequest
kubectl get certificaterequest -n production --sort-by=.metadata.creationTimestamp

# Look at ACME challenge status
kubectl get challenges -A
kubectl describe challenge -n production

# Check cert-manager controller logs for errors
kubectl logs -n cert-manager deploy/cert-manager --tail=100 | grep -i error

The Challenge resource status is especially useful — it shows exactly which DNS record or HTTP path validation is failing:

kubectl describe challenge -n production <challenge-name>
# Look for: "Reason: Failed to validate challenge..."

Monitoring the cert-manager Webhook

The webhook validates Certificate and Issuer resources on admission. If it is down, new certificates cannot be created:

# Check webhook pod health
kubectl get pods -n cert-manager

# Verify the webhook service is reachable
kubectl get validatingwebhookconfigurations cert-manager-webhook

Add a synthetic health check as a Certificate resource in a non-production namespace — if cert-manager is healthy, the cert is issued; if not, it surfaces the failure before production is affected.

Vigilmon Integration

Prometheus metrics and kubectl commands tell you what is broken; Vigilmon tells you whether your TLS-protected endpoints are actually reachable from the outside world, which is what your users experience.

Add Uptime Monitors for TLS Endpoints

For each domain cert-manager manages, add a Vigilmon HTTPS monitor:

1. Go to Monitors → Add Monitor → HTTPS
2. Set the URL to https://your-domain.example.com
3. Enable SSL certificate check and set expiry threshold to 14 days
4. Set check interval to 1 minute for production endpoints

Vigilmon will independently validate the TLS handshake and alert you if:

• The certificate is expired or invalid
• The endpoint is unreachable (separate from cert-manager itself)
• The cert chain is broken (intermediate CA issues)

Heartbeat Monitor for Renewal Jobs

If you run a custom renewal validation or cert-backup job, register it as a Vigilmon heartbeat:

# At the end of your renewal validation script:
curl -fsS "https://vigilmon.online/heartbeat/YOUR-HEARTBEAT-ID" > /dev/null

If the script stops reporting, Vigilmon fires an alert within your configured grace period.

Alerting on External TLS Failures

Set up a Vigilmon notification channel (Slack, PagerDuty, email) so that when an external TLS check fails, your on-call rotation is paged — independent of your internal Prometheus stack, which may be affected by the same cluster issue that broke cert-manager.

Summary

Robust cert-manager monitoring requires three layers:

| Layer | Tool | What It Catches | |---|---|---| | Kubernetes metrics | Prometheus | Renewal errors, ACME failures, expiry windows | | Resource inspection | kubectl | Challenge details, conditions, controller logs | | External validation | Vigilmon | Real TLS reachability from the internet |

Start with the CertificateNotReady and CertificateExpiringSoon alerts — those cover the most common failure modes. Add Vigilmon HTTPS monitors to close the loop between internal cert state and what your users actually see.