tutorial

Monitoring Kubeapps with Vigilmon: UI Availability, Helm Release Health, Helm Repository Sync & TLS Certificate Alerts

How to monitor Kubeapps with Vigilmon — UI availability checks, Helm release deployment health, Helm chart repository sync status, Kubeapps API server monitoring, and TLS certificate expiry alerts.

Kubeapps is a web-based UI for deploying and managing applications on Kubernetes via Helm — providing a catalog of Helm charts from multiple repositories and a visual interface for upgrading, rolling back, and inspecting Helm releases across namespaces. When the Kubeapps UI goes down, platform teams lose the self-service application deployment portal that dozens of engineers rely on daily. When a Helm repository sync fails, the application catalog goes stale and engineers cannot find or install the latest chart versions. When the Kubeapps API server crashes, the UI loads but every catalog and release operation fails silently with network errors. Vigilmon gives you external visibility into Kubeapps availability, Helm repository sync health, API server reachability, and the TLS layer protecting your deployment portal.

What You'll Build

  • HTTP monitor on the Kubeapps UI to detect pod crashes and ingress failures
  • SSL certificate monitor for the Kubeapps HTTPS endpoint
  • HTTP monitors on the Kubeapps API server to catch backend service failures
  • TCP monitors on the Kubeapps service port for network-layer health
  • Alerting runbook mapping Kubeapps failure modes to the right components to inspect

Prerequisites

  • A Kubernetes cluster with Kubeapps installed via the official Helm chart
  • Kubeapps exposed via Ingress or LoadBalancer
  • A free account at vigilmon.online

Step 1: Understand Kubeapps's Architecture and Health Surface

Kubeapps runs multiple components in the kubeapps namespace. Understanding the component topology is essential before setting up monitors:

# Check all Kubeapps pods
kubectl get pods -n kubeapps
# Expected running components:
# kubeapps-* (frontend UI)
# kubeapps-internal-apprepository-controller-* (Helm repo sync)
# kubeapps-internal-kubeapps-apis-* (gRPC/REST API server)
# kubeapps-internal-pinniped-proxy-* (auth proxy, if using Pinniped)

# Check the Kubeapps service
kubectl get svc -n kubeapps kubeapps
# Look for: ClusterIP or LoadBalancer type

# Check Helm repository sync status
kubectl get apprepositories -n kubeapps
# Look for: lastUpdateTime and status on each repo

The key external signals to monitor are:

  1. The Kubeapps UI HTTP/HTTPS endpoint
  2. The Kubeapps internal API server (drives catalog and release data)
  3. TLS certificate validity on the Kubeapps ingress
  4. Helm repository sync freshness

Step 2: Monitor the Kubeapps UI

The first and most visible monitor is the Kubeapps web UI. A 200 response with the Kubeapps HTML confirms the frontend pod is running and the ingress is routing correctly:

# Test the Kubeapps UI
curl -I https://kubeapps.example.com/
# Expected: HTTP/2 200 with Content-Type: text/html

# The UI serves a React SPA; check for the app root element
curl https://kubeapps.example.com/ | grep -c 'kubeapps-root\|id="root"'
  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://kubeapps.example.com/.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: kubeapps (present in the HTML <title> tag).
  7. Label: Kubeapps UI.
  8. Click Save.

This monitor detects frontend pod crashes, ingress misconfigurations, and DNS failures that prevent engineers from reaching the deployment portal.

Step 3: Monitor the Kubeapps API Server

Kubeapps's frontend communicates with an internal API server (kubeapps-internal-kubeapps-apis) that aggregates Helm release data, chart catalog information, and package repository status. When this service crashes, the UI loads but every interaction — browsing the catalog, viewing releases, deploying charts — returns network errors:

# Check the APIs service
kubectl get svc -n kubeapps kubeapps-internal-kubeapps-apis
# Internal ClusterIP service on port 8080 (gRPC) and 8081 (HTTP)

# If exposed through ingress at /api path:
curl https://kubeapps.example.com/api/v1/clusters/default/namespaces
# Expected: 200 with JSON namespace list (requires auth token)

# Health check endpoint (no auth required)
curl https://kubeapps.example.com/healthz
  1. Add Monitor → HTTP.
  2. URL: https://kubeapps.example.com/healthz (if your Kubeapps version exposes this).
  3. Check interval: 60 seconds.
  4. Expected status: 200.
  5. Label: Kubeapps API server health.
  6. Click Save.

If no health endpoint is exposed externally, monitor the UI with a keyword check on a catalog-specific HTML element that only appears when the API connection succeeds:

  1. Add Monitor → HTTP.
  2. URL: https://kubeapps.example.com/.
  3. Keyword: Available Packages (text rendered by the catalog page when API is reachable).
  4. Label: Kubeapps catalog availability.
  5. Click Save.

Step 4: Monitor the TLS Certificate

Kubeapps is a web application handling Helm deployments — its HTTPS endpoint must remain valid at all times. Certificate expiry breaks the browser connection and may also break CI/CD pipelines that interact with Kubeapps's API:

# Check the TLS secret used by the Kubeapps ingress
kubectl get ingress -n kubeapps kubeapps -o jsonpath='{.spec.tls[0].secretName}'
kubectl get secret <tls-secret-name> -n kubeapps -o jsonpath='{.data.tls\.crt}' | \
  base64 -d | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: kubeapps.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Helm chart repository TLS: If your custom Helm chart repositories are served over HTTPS (self-hosted Harbor, ChartMuseum, etc.), add SSL certificate monitors for those endpoints too. A repository TLS expiry causes Kubeapps's sync jobs to fail with TLS errors, silently staling the catalog without affecting the UI.

Step 5: Monitor Helm Repository Sync

Kubeapps syncs Helm chart repositories on a configurable schedule using the apprepository-controller. Sync failures leave the catalog stale — engineers see outdated chart versions or missing applications. While these failures are internal to the cluster, you can expose a synthetic check:

# Check AppRepository sync status
kubectl get apprepositories -n kubeapps -o json | jq '
  .items[] | {
    name: .metadata.name,
    lastUpdateTime: .status.lastUpdateTime,
    conditions: .status.conditions
  }
'

# Find repositories with sync errors
kubectl get apprepositories -n kubeapps -o json | jq '
  .items[] |
  select(.status.conditions[]?.type == "Ready" and .status.conditions[]?.status == "False") |
  {name: .metadata.name, message: .status.conditions[].message}
'

Create a CronJob to check sync freshness and alert on stale repos:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: kubeapps-repo-sync-check
  namespace: kubeapps
spec:
  schedule: "*/30 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: kubeapps-monitoring
          containers:
            - name: checker
              image: bitnami/kubectl:latest
              command:
                - /bin/sh
                - -c
                - |
                  FAILED=$(kubectl get apprepositories -n kubeapps -o json | \
                    jq '[.items[] | select(.status.conditions[]?.status == "False")] | length')
                  if [ "$FAILED" -gt "0" ]; then
                    echo "ALERT: $FAILED Helm repositories failed to sync"
                    exit 1
                  fi
          restartPolicy: Never

Pair this internal check with your Vigilmon catalog keyword monitor — when the catalog becomes stale (no new charts appearing), a sync failure is the likely root cause.

Step 6: Monitor the Kubeapps TCP Service Port

Add a TCP monitor on Kubeapps's service port to detect network-layer failures that the HTTP monitor might miss (e.g., the pod is running but the service endpoints are detached):

# Get the Kubeapps service port
kubectl get svc -n kubeapps kubeapps
# NAME       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)
# kubeapps   LoadBalancer   10.96.100.10   203.0.113.50   443:30443/TCP
  1. Add Monitor → TCP.
  2. Host: kubeapps.example.com.
  3. Port: 443.
  4. Check interval: 60 seconds.
  5. Label: Kubeapps TCP (443).
  6. Click Save.

A TCP success with an HTTP failure indicates the network connection is alive but the application layer is broken — useful for distinguishing pod failures from service/ingress misconfigurations.

Step 7: Configure Alerting

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

| Monitor | Trigger | Immediate action | |---|---|---| | Kubeapps UI HTTP | Non-200 or timeout | Check frontend pod: kubectl get pods -n kubeapps -l app.kubernetes.io/component=frontend; check ingress | | Kubeapps API health | Non-200 | Check APIs pod: kubectl logs -n kubeapps -l app.kubernetes.io/component=kubeapps-apis; restart if crash-looping | | TLS certificate | < 30 days | Check cert-manager certificate: kubectl describe certificate -n kubeapps; trigger manual renewal | | Catalog keyword | Keyword missing | Check apprepository-controller: kubectl logs -n kubeapps -l app.kubernetes.io/component=apprepository-controller | | TCP (443) | Connection refused | Check LoadBalancer service: kubectl get svc -n kubeapps kubeapps; check node health |

Alert grouping: Create a kubeapps monitor group. When the APIs service crashes, both the catalog keyword check and API health monitor fire together — the group view makes it immediately clear the issue is in the backend, not the frontend pod.

Common Kubeapps Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon signal | |---|---| | Kubeapps frontend pod OOMKilled | HTTP monitor fires with 502 | | kubeapps-apis pod crash-loops | Catalog keyword monitor fails (page loads but no packages listed); API health monitor fires | | Helm repository sync fails (bad URL or auth) | Catalog becomes stale; keyword check shows outdated chart versions | | TLS certificate expires on ingress | SSL monitor fires at 30-day threshold; HTTP monitor fires with TLS error on expiry day | | Ingress controller upgrade breaks routing | HTTP monitor fires; TCP monitor stays green (isolating the ingress layer) | | apprepository-controller crash | No sync jobs run; repositories stay stale; catalog keyword check misses new chart versions | | Kubeapps upgraded with breaking chart change | HTTP monitor detects downtime during upgrade rollout | | Pinniped proxy misconfiguration | UI loads but login fails; catalog pages return 401 | | LoadBalancer IP de-provisioned | TCP monitor fires; HTTP and keyword monitors also fire simultaneously | | Namespace deletion removes apprepository | Specific repo's charts disappear from catalog; keyword check misses apps from that repo |

Kubeapps is the self-service deployment layer that lets platform teams give engineers access to Helm charts without granting direct Kubernetes access — making its availability critical to development velocity. Vigilmon gives you external visibility into UI availability, API server health, catalog freshness, and TLS validity. When an apprepository-controller crash stales the Helm catalog or a certificate expiry breaks the deployment portal, Vigilmon alerts you before engineers start filing "Kubeapps is broken" tickets.

Start monitoring your Kubeapps instance 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