tutorial

Monitoring Kubefirst with Vigilmon: Console UI, Argo CD Sync, Vault Health & Registry Connectivity Alerts

How to monitor Kubefirst with Vigilmon — console availability, cluster provisioning health, GitOps sync status, HashiCorp Vault integration, and container registry connectivity.

Kubefirst is the GitOps-native Kubernetes bootstrap platform that automates provisioning of a complete platform engineering environment — Argo CD, HashiCorp Vault, container registry integration, and DNS in a single kubefirst cluster create command. Because Kubefirst wires together multiple third-party services as a single system, a failure in any component silently breaks the entire GitOps delivery pipeline: when Vault is unreachable, secrets injection stops; when the container registry becomes inaccessible, deployments fail; when Argo CD's API server goes down, engineers lose the ability to sync applications. Vigilmon gives you external visibility into every layer of a Kubefirst-provisioned cluster: the management console, the GitOps engine, the secrets backend, and the registry gateway.

What You'll Build

  • A Vigilmon monitor on the Kubefirst console UI to detect management plane failures
  • An Argo CD health API check for GitOps sync engine availability
  • A HashiCorp Vault availability monitor to catch secrets backend outages
  • A container registry connectivity check to prevent deployment failures
  • SSL certificate monitoring across all platform endpoints
  • A consolidated alerting setup that distinguishes infrastructure failures from application failures

Prerequisites

  • A running Kubefirst-provisioned cluster (AWS, GCP, Azure, or Civo)
  • The Kubefirst console accessible externally (typically via an ingress with a DNS-managed domain)
  • Argo CD, Vault, and your container registry exposed via ingress or LoadBalancer
  • A free account at vigilmon.online

Step 1: Understand Kubefirst's Component Architecture

A Kubefirst-provisioned cluster includes these externally accessible components:

| Component | Default path | Purpose | |---|---|---| | Kubefirst console | https://kubefirst.example.com | Cluster management UI | | Argo CD | https://argocd.example.com | GitOps sync engine | | HashiCorp Vault | https://vault.example.com | Secrets management | | Container registry | https://registry.example.com | Image push/pull gateway | | Argo Workflows | https://argo.example.com | CI pipeline orchestration |

Kubefirst configures all of these via an Nginx ingress controller with cert-manager-issued TLS certificates. Each service exposes a health or readiness endpoint that Vigilmon can probe without requiring authentication (with the exception of Vault, which requires an explicit unauthenticated health path).

Step 2: Monitor the Kubefirst Console UI

The Kubefirst console at https://kubefirst.{your-domain} is the management interface for cluster operations. When it's unavailable, platform engineers can't provision new environments, inspect cluster drift, or access provisioning logs:

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

If Kubefirst doesn't expose a /health endpoint in your version, monitor the root path and check for a known UI keyword:

  1. URL: https://kubefirst.example.com
  2. Expected status: 200
  3. Keyword: kubefirst (appears in the HTML page title).

Alert sensitivity: 1 consecutive failure. Console unavailability blocks all cluster management operations.

Step 3: Monitor Argo CD GitOps Health

Argo CD is the GitOps engine at the core of every Kubefirst cluster. The /healthz endpoint confirms the API server is running and the application controller can reach the Kubernetes API:

curl https://argocd.example.com/healthz
# Returns: ok
  1. Add Monitor → HTTP.
  2. URL: https://argocd.example.com/healthz
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: ok.
  7. Label: Kubefirst Argo CD.
  8. Click Save.

Then monitor the Argo CD web UI separately to distinguish API failures from UI rendering issues:

  1. Add Monitor → HTTP.
  2. URL: https://argocd.example.com
  3. Check interval: 2 minutes.
  4. Expected status: 200.
  5. Keyword: Argo CD.
  6. Label: Kubefirst Argo CD UI.
  7. Click Save.

GitOps sync failures: Argo CD health only confirms the server is running, not that sync is actually happening. Application-level sync failures (Git connection errors, resource conflicts, image pull errors) don't show up in the /healthz probe — use Argo CD's own application health indicators for those.

Step 4: Monitor HashiCorp Vault

Kubefirst provisions HashiCorp Vault to manage all secrets injected into cluster workloads via the Vault Agent Injector and External Secrets Operator. When Vault is sealed or unreachable, every new pod that mounts a Vault secret fails to start, and existing pods can't renew their short-lived secrets leases.

Vault exposes an unauthenticated health endpoint at /v1/sys/health:

curl https://vault.example.com/v1/sys/health

The response codes carry meaning:

  • 200 — initialized, unsealed, and active
  • 429 — unsealed and standby (HA mode)
  • 472 — disaster recovery mode replication secondary
  • 503 — sealed or uninitialized

For monitoring purposes, you want to alert on anything that isn't 200 or 429:

  1. Add Monitor → HTTP.
  2. URL: https://vault.example.com/v1/sys/health
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200 (or configure to accept 200 and 429 for HA setups).
  6. Keyword: initialized (present in healthy Vault JSON responses).
  7. Label: Kubefirst Vault.
  8. Click Save.

Vault sealing events: Vault can be automatically sealed by the cloud KMS if the auto-unseal key is revoked, or manually sealed by an operator. A 503 from this endpoint means every workload that tries to read secrets will fail to mount. This is a critical alert that warrants immediate response.

Also monitor the Vault UI availability:

  1. Add Monitor → HTTP.
  2. URL: https://vault.example.com/ui/
  3. Check interval: 2 minutes.
  4. Expected status: 200.
  5. Keyword: Vault.
  6. Label: Kubefirst Vault UI.
  7. Click Save.

Step 5: Monitor Container Registry Connectivity

Kubefirst integrates with a container registry (GitHub Container Registry, AWS ECR via a proxy, or a self-hosted Harbor instance) for storing and serving application images. When the registry is unreachable, Kubernetes cannot pull new images, and deployments fail with ImagePullBackOff or ErrImagePull errors across all workloads.

For a self-hosted Harbor registry:

curl https://registry.example.com/api/v2.0/ping
# Returns: {"message": "pong"}
  1. Add Monitor → HTTP.
  2. URL: https://registry.example.com/api/v2.0/ping (Harbor) or https://registry.example.com/v2/ (generic OCI registry).
  3. Check interval: 2 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: pong (Harbor) or accept any 200 for OCI v2.
  7. Label: Kubefirst container registry.
  8. Click Save.

For GitHub Container Registry via an ingress proxy:

  1. URL: https://ghcr-proxy.example.com/v2/
  2. Expected status: 200 or 401 (unauthenticated access returns 401 on a healthy OCI registry).
  3. Label: Kubefirst GHCR proxy.

A 401 on /v2/ means the registry is reachable and enforcing authentication — which is correct behavior. A connection failure or 502 means the proxy itself is down. Configure your Vigilmon monitor to accept 200 and 401 as both-healthy responses.

Step 6: Monitor Argo Workflows (CI Pipeline Engine)

Kubefirst provisions Argo Workflows as the CI pipeline runner for the GitOps delivery flow. When Argo Workflows is unavailable, new commits can't trigger image builds and the GitOps delivery loop breaks:

curl https://argo.example.com/health
# Returns: {"status":"ok"}
  1. Add Monitor → HTTP.
  2. URL: https://argo.example.com/health
  3. Check interval: 2 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: ok.
  7. Label: Kubefirst Argo Workflows.
  8. Click Save.

Step 7: SSL Certificate Monitoring for All Platform Endpoints

Kubefirst uses cert-manager to issue Let's Encrypt certificates for all ingress endpoints. Certificates expire and renewal can fail silently if the ACME challenge is blocked by a NetworkPolicy change, if the ClusterIssuer hits Let's Encrypt rate limits, or if a DNS change breaks the HTTP-01 validation:

  1. Add Monitor → SSL Certificate for each platform endpoint:
    • kubefirst.example.com
    • argocd.example.com
    • vault.example.com
    • registry.example.com
    • argo.example.com
  2. Alert when expiry is within: 30 days.
  3. Alert again: 14 days, 7 days.

Cert-manager batch renewals: cert-manager renews certificates when they reach 2/3 of their validity period. Let's Encrypt certificates are valid 90 days, so renewal happens around day 60. A 30-day alert window gives you 30 days of buffer if automated renewal fails — well within the window to renew manually before any service disruption.

Step 8: Configure Consolidated Alerting

In Vigilmon under Settings → Notifications, configure your alerting logic:

| Monitor | Trigger | Action | |---|---|---| | Kubefirst console | Non-200 or ok missing | Check console pod; run kubectl get pods -n kubefirst | | Argo CD health | Non-200 or ok missing | Check Argo CD API server; kubectl get pods -n argocd | | Vault health | 503 (sealed) | Unseal Vault; check auto-unseal KMS key; run vault status | | Vault health | 401 or connection error | Vault completely unreachable; check Vault pod and ingress | | Container registry | Connection failed | Image pulls failing; check registry pod; kubectl describe pod <failing-pod> | | Argo Workflows | Non-200 | CI pipeline broken; check Argo Workflows controller | | SSL certificates | < 30 days to expiry | Check cert-manager events; kubectl get certificate -n ingress-nginx |

Alert after: 1 consecutive failure for Vault and Argo CD health monitors. 2 consecutive failures for console and registry monitors.

Common Kubefirst Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Kubefirst console pod OOM killed | Console health monitor fires | | Argo CD application controller crash | Argo CD health API returns non-200 | | Vault sealed after KMS key rotation | Vault health returns 503; secrets injection stops | | Vault HA standby promoted incorrectly | Vault health returns unexpected status code | | Container registry out of disk space | Registry monitor times out or returns 5xx | | Let's Encrypt cert-manager renewal failure | SSL monitors fire at 30-day threshold | | Ingress controller upgraded with breaking change | All monitors fire simultaneously | | DNS misconfiguration after platform migration | All monitors fail; DNS resolution errors | | Argo Workflows controller memory pressure | Argo Workflows health monitor fires; CI jobs queue | | Registry proxy authentication failure | Registry monitor returns 401 unexpectedly |

Kubefirst condenses months of platform engineering work into a single bootstrap command — but that tight integration means a failure in any component can cascade through the entire delivery pipeline. Vigilmon gives your team external visibility into the console, the GitOps sync engine, the secrets backend, the container registry, and the CI pipeline engine, so you know the moment any layer of your Kubefirst-provisioned platform becomes unavailable and can restore delivery operations before developers notice their deploys are stalled.

Start monitoring your Kubefirst platform 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