Kubero Monitoring with Vigilmon
Kubero is a self-hosted PaaS platform that runs on Kubernetes or K3s and provides a Heroku-style deployment experience for teams that want to own their infrastructure. It bundles a web UI, a Kubernetes operator, a build pipeline, and addon provisioning — letting developers push code, trigger builds, and manage addons without needing Kubernetes expertise. Engineering teams use Kubero to reduce the operational overhead of Kubernetes while retaining full control over their cluster.
Because Kubero orchestrates application deployments and build pipelines on top of Kubernetes, silent failures in any layer — the web UI, the operator, or the Kubernetes API connection — can block all deployments and leave running applications unscaled and unmanaged.
This guide covers how to monitor Kubero with Vigilmon.
Why Kubero Needs Monitoring
Kubero failures can block deployments and leave applications unmanaged:
- Web UI crash — the Node.js server stops responding; developers cannot trigger deployments, review build logs, or manage addons through the dashboard
- Kubernetes API disconnection — Kubero loses its connection to the Kubernetes API server; the operator cannot create, update, or delete pods, and all deployments stall silently
- Operator pod failure — the Kubero operator pod crashes or enters CrashLoopBackOff; new deployments are accepted by the API but never applied to the cluster
- Build pipeline failure — the build service cannot pull source code, run build steps, or push images; application updates are queued but never executed
- Addon provisioning failure — the addon controller cannot provision or deprovision databases, caches, or other services; addon-dependent applications are blocked from deploying
- Ingress controller integration failure — Kubero cannot create or update ingress resources; newly deployed applications are not routable from the outside
Vigilmon monitors all of these failure modes so your team is alerted before a Kubero failure silently blocks your deployment pipeline.
Kubero Architecture Overview
| Component | Default Port | Role | Monitoring Priority | |-----------|-------------|------|---------------------| | Kubero web server (Node.js) | 3000 | Web UI and REST API | Critical | | Kubero operator | Kubernetes pod | CRD controller and reconciliation | Critical | | Kubernetes API server | 6443 (K3s default) | Cluster control plane | Critical | | Build pipeline service | Internal | Source fetch, build, image push | High | | Ingress controller | 80/443 | Application routing | High |
Monitor 1: Kubero Web UI Availability
Monitor the Kubero login page to confirm the Node.js server is up:
- Log in to Vigilmon → Monitors → New Monitor
- Type: HTTP
- Name:
Kubero - Web UI - URL:
http://your-kubero-host:3000/ - Method: GET
- Expected status: 200
- Keyword check:
Kubero - Interval: 1 minute
Test your endpoint:
curl -s http://your-kubero-host:3000/ | grep -i "kubero"
# Expected: HTML containing "Kubero"
Monitor 2: Kubero API Health
The Kubero REST API exposes a health or version endpoint. A successful response confirms the API is routing and the Node.js process is healthy:
- Type: HTTP
- Name:
Kubero - API Health - URL:
http://your-kubero-host:3000/api/health - Method: GET
- Expected status: 200
- Interval: 2 minutes
curl -s http://your-kubero-host:3000/api/health
# Expected: {"status":"ok"} or similar (HTTP 200)
If /api/health returns 404 for your Kubero version, use /api/version as a fallback:
curl -s -o /dev/null -w "%{http_code}" http://your-kubero-host:3000/api/version
# Expected: 200
Monitor 3: Kubernetes API Connectivity
Kubero depends on a live connection to the Kubernetes API server. Monitor the K3s/Kubernetes API health endpoint to catch cluster control-plane failures before they surface as stalled deployments:
- Type: HTTP
- Name:
Kubero - Kubernetes API - URL:
https://your-k3s-host:6443/healthz - Method: GET
- Expected status: 200
- Keyword check:
ok - Interval: 1 minute
curl -sk https://your-k3s-host:6443/healthz
# Expected: ok
If TLS verification fails due to a self-signed certificate, configure Vigilmon to skip TLS verification for this internal endpoint, or pass the cluster CA certificate.
Monitor 4: Kubero Operator Pod Health (Kubernetes Readiness)
The Kubero operator runs as a Kubernetes deployment. Monitor its readiness endpoint via the Kubernetes API to detect CrashLoopBackOff or evicted pods:
- Type: HTTP
- Name:
Kubero - Operator Pod Ready - URL:
https://your-k3s-host:6443/apis/apps/v1/namespaces/kubero/deployments/kubero-operator - Method: GET
- Expected status: 200
- Interval: 2 minutes
- Authentication: Kubernetes service account Bearer token
# Check operator deployment status
kubectl get deployment kubero-operator -n kubero -o jsonpath='{.status.readyReplicas}'
# Expected: 1 (or your configured replica count)
# Alert if readyReplicas < 1
As an alternative to direct Kubernetes API monitoring, set up a heartbeat script that polls the deployment status and pings Vigilmon (see Monitor 6).
Monitor 5: SSL Certificate Alert
If Kubero is exposed via HTTPS:
- Type: HTTP
- Name:
Kubero - SSL Certificate - URL:
https://kubero.your-domain.com/ - SSL certificate expiry alert: 21 days before expiry
- Interval: 1 hour
curl -vI https://kubero.your-domain.com/ 2>&1 | grep "expire date"
Monitor 6: Kubero Deployment Pipeline Heartbeat
An hourly end-to-end check that authenticates to Kubero, lists applications, and verifies the Kubernetes operator connection. This catches operator failures and Kubernetes API disconnections before they block a deployment:
Heartbeat Script
#!/bin/bash
# kubero-heartbeat.sh — run hourly via cron
set -euo pipefail
KUBERO_URL="http://your-kubero-host:3000"
KUBERO_USER="admin"
KUBERO_PASS="$KUBERO_HEARTBEAT_PASSWORD"
VIGILMON_HEARTBEAT="YOUR_HEARTBEAT_ID"
# Step 1: Authenticate
AUTH_RESPONSE=$(curl -s -X POST \
-H "Content-Type: application/json" \
-d "{\"user\":\"${KUBERO_USER}\",\"password\":\"${KUBERO_PASS}\"}" \
"${KUBERO_URL}/api/auth/login")
TOKEN=$(echo "$AUTH_RESPONSE" | python3 -c "import sys,json; print(json.load(sys.stdin).get('token',''))" 2>/dev/null)
if [ -z "$TOKEN" ]; then
echo "[kubero-hb] Authentication failed"
exit 1
fi
# Step 2: List pipelines (verifies Kubernetes API connectivity)
PIPELINES_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
-H "Authorization: Bearer $TOKEN" \
"${KUBERO_URL}/api/pipelines")
if [ "$PIPELINES_STATUS" -ne 200 ]; then
echo "[kubero-hb] Pipeline list returned $PIPELINES_STATUS (Kubernetes API may be disconnected)"
exit 1
fi
# Step 3: Check operator pod via kubectl (requires kubeconfig)
OPERATOR_READY=$(kubectl get deployment kubero-operator -n kubero \
-o jsonpath='{.status.readyReplicas}' 2>/dev/null || echo "0")
if [ "$OPERATOR_READY" -lt 1 ]; then
echo "[kubero-hb] Operator has $OPERATOR_READY ready replicas (expected ≥1)"
exit 1
fi
echo "[kubero-hb] Web UI, Kubernetes API, and operator all healthy"
# Step 4: Signal Vigilmon
curl -s "https://heartbeat.vigilmon.online/$VIGILMON_HEARTBEAT"
Add to cron:
# /etc/cron.d/kubero-heartbeat
0 * * * * root /opt/kubero/kubero-heartbeat.sh >> /var/log/kubero-heartbeat.log 2>&1
In Vigilmon:
- Type: Heartbeat
- Name:
Kubero - Deployment Pipeline - Expected interval: 1 hour
- Grace period: 10 minutes
Alert Configuration
| Monitor | Type | Interval | Alert Channel | |---------|------|----------|---------------| | Web UI | HTTP | 1 min | Slack + Email | | API health | HTTP | 2 min | Slack | | Kubernetes API | HTTP | 1 min | PagerDuty + Slack | | Operator pod ready | HTTP | 2 min | PagerDuty + Slack | | SSL certificate | HTTP | 1 hour | Email (21-day lead) | | Deployment pipeline | Heartbeat | 1 hour | PagerDuty + Email |
Use PagerDuty or phone alerts for Kubernetes API and operator monitors. A Kubernetes API disconnection silently blocks all deployments — developers will push code, see no errors in Kubero, and only discover the issue when their changes never appear in the cluster.
Status Page
- Status Pages → New Page → name it "Kubero PaaS Platform"
- Add all monitors above
- Share with your engineering and platform team
When developers report that deployments appear to queue but never complete, they can check this page to identify whether the Kubernetes API or operator is the root cause.
Summary
Kubero is a multi-layer PaaS platform where failures in any component — web UI, Kubernetes API, or operator — silently block deployments. Vigilmon keeps the full stack monitored:
- HTTP monitors for web UI availability, API health, Kubernetes API reachability, and operator pod readiness
- SSL certificate monitoring with a 21-day lead time for HTTPS deployments
- Hourly heartbeat that authenticates, lists pipelines, and verifies the operator is healthy — catching disconnections and pod failures before they block the next deployment
Get started at vigilmon.online.