Monitoring Helm Dashboard with Vigilmon: UI Availability, API Health, Port Reachability & SSL Certificate Alerts

Helm Dashboard is the open-source visual UI for Helm — giving platform teams and developers a browser-based interface to inspect deployed releases, review chart differences, roll back to previous revisions, and visualise Kubernetes resource manifests without running helm list commands in a terminal. When Helm Dashboard goes down, engineers lose their primary tool for understanding what's deployed in the cluster and must fall back to raw kubectl and helm CLI commands. Vigilmon gives you external visibility into Helm Dashboard's availability so your team knows the moment their Kubernetes operations UI goes offline.

What You'll Build

A web UI availability monitor to confirm Helm Dashboard is accessible
An API health monitor for Helm Dashboard's backend REST API
A TCP port monitor to verify the server process is listening
SSL certificate monitoring if Helm Dashboard is exposed over HTTPS
An alerting configuration that isolates UI failures from backend API failures

Prerequisites

Helm Dashboard installed and running (via Helm chart or helm dashboard plugin)
Accessible over a public or private URL (e.g., https://helm-dashboard.example.com or a NodePort)
A free account at vigilmon.online

Step 1: Understand How Helm Dashboard Serves Traffic

Helm Dashboard runs as a single Go binary that serves both its web UI (React frontend) and its REST API from the same port (default: 8080). When running with the Helm plugin, it binds to localhost:8080 by default. For team access, it's typically deployed as a Kubernetes Deployment with an Ingress:

# Test the root path (serves the React frontend)
curl http://helm-dashboard.example.com:8080
# Returns: HTML with "Helm Dashboard" in the page content

# Test the API health
curl http://helm-dashboard.example.com:8080/api/health
# Returns: {"healthy":true} or similar

If you've deployed Helm Dashboard via the official Helm chart (komodorio/helm-dashboard), it may be exposed on port 8080 via a Service with an optional Ingress. Confirm the external URL and port before configuring monitors.

Step 2: Create a Vigilmon HTTP Monitor for the Web UI

Log in to Vigilmon → Add Monitor → HTTP.
URL: https://helm-dashboard.example.com (or http:// if not TLS-terminated).
Check interval: 2 minutes.
Response timeout: 15 seconds.
Expected status: 200.
Keyword: Helm Dashboard (present in the page title and HTML content of the UI).
Label: Helm Dashboard web UI.
Click Save.

This monitor catches:

Helm Dashboard pod crashes or OOM kills
React frontend serving failures
Kubernetes Deployment rollout failures after chart upgrades
Ingress controller misconfigurations that return 502 or 503 errors
Node drain events that temporarily take Helm Dashboard offline

Alert sensitivity: Set to trigger after 2 consecutive failures to absorb brief pod restart events. Helm Dashboard is a convenience tool; a brief restart shouldn't page on-call engineers, but sustained downtime should.

Step 3: Monitor the Helm Dashboard REST API

Helm Dashboard's React frontend communicates with a Go backend API that queries the Kubernetes API server for release data. An API failure produces a broken UI: the page loads but all releases show loading spinners indefinitely. You can distinguish this failure mode with a dedicated API monitor:

curl https://helm-dashboard.example.com/api/helm/release/list
# Returns: [] or a JSON array of Helm releases

curl https://helm-dashboard.example.com/api/v1/repositories
# Returns: JSON array of configured chart repositories

For a robust health check, target an API endpoint that doesn't require specific state:

Add Monitor → HTTP.
URL: https://helm-dashboard.example.com/api/helm/release/list.
Check interval: 2 minutes.
Response timeout: 15 seconds.
Expected status: 200.
Keyword: [ (present in all valid JSON array responses, including an empty release list).
Label: Helm Dashboard API.
Click Save.

When the API monitor fires but the web UI monitor stays green, the frontend is serving correctly but the backend cannot reach the Kubernetes API server. This typically means the Helm Dashboard service account lacks RBAC permissions, or the Kubernetes API server is overloaded.

Step 4: Monitor the Port via TCP Check

A TCP check confirms that the Helm Dashboard process is listening on its port, independent of whether the HTTP layer returns the correct content. This catches cases where the process starts but the HTTP router fails to initialize:

nc -zv helm-dashboard.example.com 443
# Or for HTTP-only deployments:
nc -zv helm-dashboard.example.com 8080

Add Monitor → TCP.
Host: helm-dashboard.example.com.
Port: 443 (HTTPS) or 8080 (direct port access).
Check interval: 2 minutes.
Label: Helm Dashboard TCP port.
Click Save.

When the TCP monitor fires but nothing else does: this indicates a firewall rule or Kubernetes NetworkPolicy is blocking inbound traffic to the Helm Dashboard service. Because HTTP-level monitors time out on connection failure, the TCP check surfaces this failure faster and more clearly.

Step 5: Monitor SSL Certificates

If Helm Dashboard is exposed over HTTPS (recommended for any multi-user deployment), monitor the certificate for expiry:

openssl s_client -connect helm-dashboard.example.com:443 2>/dev/null | openssl x509 -noout -dates

Add Monitor → SSL Certificate.
Domain: helm-dashboard.example.com.
Alert when expiry is within: 30 days.
Alert again: 14 days, 7 days, 3 days, 1 day.
Click Save.

Helm Dashboard is often deployed inside a corporate VPN or internal cluster without automated certificate management. In these environments, manually-managed certificates are common and frequently overlooked at renewal time. A 30-day alert window provides enough runway to request and deploy a new certificate through your PKI process.

Step 6: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Web UI | Non-200 or keyword missing | Check pod: kubectl get pods -n helm-dashboard | | REST API | Non-200 or [ missing | Check RBAC and Kubernetes API server reachability | | TCP port | Connection refused | Check NetworkPolicy and Service endpoint configuration | | SSL certificate | < 30 days to expiry | Renew certificate; check cert-manager or manual cert status |

Recommended routing: Send web UI and API alerts to the platform team Slack channel. Route SSL certificate alerts to the infrastructure team with a 30-day lead time.

Common Helm Dashboard Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Pod OOM killed | Web UI and API monitors fire within 2 minutes | | Kubernetes API server RBAC revoked | API monitor fires; web UI may still serve static assets | | Ingress controller misconfiguration | Web UI and API monitors fire simultaneously | | TCP port blocked by firewall change | TCP monitor fires; HTTP monitors time out | | SSL certificate expires | SSL monitor fires at 30-day threshold; all HTTPS access fails | | Node drain during maintenance | All monitors fire temporarily; resolve on pod reschedule | | Chart upgrade introduces breaking change | API monitor fires if new routes change; check Helm Dashboard release notes | | Kubernetes API server degraded | API monitor fires; pod-level monitors may show degraded release data | | DNS record change breaks hostname resolution | All monitors fire simultaneously | | Insufficient CPU/memory causes slow responses | HTTP monitors fire on response timeout; check HorizontalPodAutoscaler |

Helm Dashboard reduces the cognitive overhead of managing Helm releases across Kubernetes clusters — but when it's unavailable, teams revert to manual CLI workflows that are slower and more error-prone. Vigilmon gives you external eyes on every availability layer — the UI, the REST API, the port, and the certificate — so you know immediately when Helm Dashboard needs attention.

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