tutorial

Monitoring helmwave Deployments with Vigilmon: Service Health, TCP Ports, SSL Certificates & Release Alerts

How to monitor helmwave-managed Kubernetes deployments with Vigilmon — HTTP health checks for released services, TCP port checks, SSL certificate monitoring, and CI pipeline alerts.

helmwave is a Helm-native deployment tool that lets you declare your entire Kubernetes release state in a helmwave.yml file, supports templating with Go, and runs releases in dependency-aware topological order. It is built for modern GitOps workflows: commit a change to helmwave.yml, run helmwave up, and all affected releases are upgraded in the correct order. When a release upgrade degrades a service, when a dependency order failure leaves downstream releases running on stale dependencies, or when a helmwave up run in CI exits without completing all releases, users encounter failures that the cluster's internal probes never surface. Vigilmon gives you external uptime coverage across every HTTP endpoint, TCP port, and TLS certificate in your helmwave-managed cluster.

What You'll Build

  • HTTP health monitors for each helmwave release that serves external traffic
  • TCP port checks for ingress controllers managed as helmwave releases
  • SSL certificate monitoring for TLS-enabled helmwave ingresses
  • An alerting configuration that maps fired alerts to specific helmwave.yml releases
  • CI pipeline availability checks for helmwave deployments

Prerequisites

  • A Kubernetes cluster with helmwave managing Helm chart releases
  • At least one release exposed via an Ingress or LoadBalancer with a health check endpoint
  • HTTPS configured for your public domains
  • A free account at vigilmon.online

Step 1: Understand helmwave's Release Model and Failure Surface

helmwave reads a helmwave.yml that defines releases, their dependencies, and their values:

# helmwave.yml excerpt
project: my-platform
version: "0.40.0"

releases:
  - name: ingress-nginx
    namespace: ingress-nginx
    chart:
      name: ingress-nginx/ingress-nginx
      version: "4.8.3"

  - name: cert-manager
    namespace: cert-manager
    chart:
      name: jetstack/cert-manager
      version: "v1.13.0"
    depends_on:
      - ingress-nginx@ingress-nginx

  - name: api
    namespace: production
    chart:
      name: ./charts/api
    depends_on:
      - ingress-nginx@ingress-nginx
      - cert-manager@cert-manager
    values:
      - ./environments/production/api.yaml

helmwave runs releases in dependency order but stops at the first release failure. This creates distinctive failure patterns that differ from tools that attempt all releases regardless of failures:

  • Foundational release fails: ingress-nginx fails → all dependent releases never run → multiple services unreachable simultaneously
  • Mid-dependency failure: cert-manager release fails → api never starts → no new certificates issued for any downstream release
  • Release succeeds at Helm level, pods crash-loop: helmwave exits 0 but the upgraded image is broken
  • Values template renders incorrectly: wrong configuration applied; pods stay Running but service misbehaves
  • CI cancellation mid-run: some releases upgraded, others not; cluster is in a split state

Step 2: Create Health Monitors for helmwave Releases

For each release in your helmwave.yml that exposes external traffic, create a Vigilmon HTTP monitor.

API release:

curl https://api.example.com/health
# Expected: 200 {"status":"ok"}
  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://api.example.com/health.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: ok.
  7. Label: helmwave/api production.
  8. Click Save.

Label each monitor helmwave/<release-name> <namespace> to match the name and namespace fields in your helmwave.yml. When an alert fires, you can immediately run:

helm status api -n production
helmwave status

Alert sensitivity: 1 consecutive failure for production releases. helmwave deployments applied to stable clusters do not produce transient failures; a single missed check indicates a real incident.

Step 3: Monitor the Ingress Controller TCP Port

helmwave's depends_on graph typically puts the ingress controller at the root of the dependency tree. If the ingress release fails or the cloud LoadBalancer becomes unhealthy, all downstream services are unreachable simultaneously — but the cause is the ingress layer, not the individual application releases:

# TCP-level check on the ingress LoadBalancer
nc -zv ingress.example.com 443
  1. Add Monitor → TCP.
  2. Host: the external hostname or IP of your ingress controller.
  3. Port: 443.
  4. Check interval: 2 minutes.
  5. Label: helmwave/ingress-nginx LoadBalancer.
  6. Click Save.

Correlating helmwave dependency failures: If the TCP ingress monitor fires at the same time as all HTTP release monitors, the root cause is the ingress-nginx release or its underlying LoadBalancer. Run helm status ingress-nginx -n ingress-nginx and kubectl get events -n ingress-nginx --sort-by='.lastTimestamp' to pinpoint the issue. If only one HTTP monitor fires while the TCP monitor stays green, the failure is scoped to that specific helmwave release.

Step 4: Monitor SSL Certificates for helmwave TLS Releases

helmwave often manages cert-manager as a dependency release. A failed cert-manager upgrade — or a helmwave up run cancelled after ingress-nginx completes but before cert-manager runs — can leave certificate renewal broken without any immediate error:

# Check certificate validity
openssl s_client -connect api.example.com:443 2>/dev/null | openssl x509 -noout -dates

For each domain served by a helmwave-managed Ingress:

  1. Add Monitor → SSL Certificate.
  2. Domain: api.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

helmwave and cert-manager dependency ordering: The depends_on chain ensures cert-manager is deployed before application releases that need certificates. But if a partial helmwave up run is cancelled mid-dependency-graph, cert-manager may be on an older chart version while the application releases that issued certificates against it are now on a newer API. The 30-day SSL alert window catches this well before any certificate expires.

Step 5: Monitor Your helmwave CI Run

helmwave is designed to run in CI pipelines. If the CI job is cancelled, times out, or its runner goes offline mid-release, the dependency graph is abandoned and the cluster may be in an inconsistent partial-upgrade state. Monitor the CI system itself to catch availability gaps:

# Verify CI is reachable
curl https://ci.example.com/health

Or monitor a deployment webhook endpoint that your CI posts to on success:

  1. Add Monitor → HTTP.
  2. URL: your CI pipeline status URL or post-deploy webhook endpoint.
  3. Check interval: 5 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Label: helmwave CI pipeline.
  7. Click Save.

If your CI system does not expose a status URL, the HTTP release monitors catch any downstream impact of skipped helmwave up runs.

Step 6: Configure Alerting

In Vigilmon under Settings → Notifications, configure alert channels and runbooks:

| Monitor | Trigger | Action | |---|---|---| | helmwave/<release> <ns> HTTP | Non-200 or keyword missing | helm status <release> -n <ns>; check helmwave status; inspect pod logs | | TCP ingress port 443 | Connection refused | helm status ingress-nginx -n ingress-nginx; check cloud LB; inspect depends_on chain | | SSL certificate | < 30 days expiry | Check cert-manager release: helm status cert-manager -n cert-manager; inspect kubectl get certificate | | CI pipeline | Non-200 | Review helmwave up CI logs; check for dependency-order failures; verify all releases reached deployed state |

Routing strategy: Route release monitors to the team that owns each chart in helmwave.yml. Route TCP ingress and SSL monitors to the platform team. helmwave's dependency ordering means cascading failures often have a single upstream cause — the alert pattern (which monitors fired, in what order) tells you where in the dependency graph the failure occurred.

Common helmwave Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Image tag in values not found; release upgrade fails | HTTP monitor fires for that release; others stay green | | ingress-nginx release fails; dependency chain halted | TCP ingress + all HTTP release monitors fire simultaneously | | cert-manager release fails mid-dependency-graph; new certs not issued | SSL certificate monitors fire at 30-day threshold | | CI runner cancelled mid-helmwave up; partial release state | HTTP monitors catch degraded services from incomplete upgrades | | Helm release succeeds; pods crash-loop on new image | HTTP monitor returns 502; helm status shows deployed (misleading) | | Wrong values template rendered; service misconfigured | HTTP keyword monitor catches missing expected content | | Cloud LoadBalancer external IP changes | TCP ingress + all HTTP monitors fire; kubectl get svc confirms IP change | | helmwave.yml depends_on cycle introduced by refactor | helmwave up fails immediately; HTTP monitors catch stale state |

helmwave's topological release ordering and declarative YAML model make Kubernetes deployments reproducible and dependency-aware — but once a release is applied, helmwave steps aside. The running cluster is unmonitored by the tool itself. Vigilmon provides continuous external verification of every service helmwave deploys: HTTP health checks, TCP ingress port monitoring, SSL certificate expiry alerts, and CI pipeline availability — so you know immediately when a helmwave deployment's real-world outcome diverges from its declared desired state.

Start monitoring your helmwave deployments in under 5 minutes — register free at vigilmon.online.

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