tutorial

Monitoring Upbound with Vigilmon: Keeping Your Managed Control Planes and Upbound Cloud Healthy

How to monitor Upbound with Vigilmon — tracking managed control plane health, Upbound Cloud API availability, marketplace configuration sync, and provider reconciliation from outside the platform.

Upbound is the commercial Crossplane platform that turns infrastructure management into a product. Managed control planes (MCPs) on Upbound Cloud give you isolated Crossplane instances per team or environment without the operational overhead of running your own clusters. The Upbound Marketplace lets you publish and consume Crossplane configurations. When Upbound is unhealthy — an MCP goes down, the Upbound API is unavailable, a configuration sync stalls — your entire infrastructure-as-code workflow breaks. Teams can't provision resources, pipelines fail silently, and the visibility you expect from a managed platform evaporates. Vigilmon gives you external monitoring that watches Upbound from outside the platform and alerts the moment something breaks.

What You'll Build

  • Vigilmon HTTP monitors for Upbound Cloud API endpoints
  • Heartbeat monitors for managed control plane reconciliation activity
  • Monitors for the Upbound CLI connectivity and configuration sync
  • Alert channels for your platform team

Prerequisites

  • An Upbound Cloud account with at least one managed control plane (MCP)
  • The up CLI installed and configured
  • A free account at vigilmon.online

Why Monitoring Upbound Matters

Upbound abstracts the Kubernetes cluster, but the failure modes of the infrastructure-management layer remain. External monitoring catches what Upbound's own dashboards miss from the outside:

Managed control plane downtime is the primary failure mode. If the MCP backing a team's infrastructure goes unavailable, all their resource claims stop reconciling — exactly like a Crossplane controller crash, but in a managed tier where you have less visibility into what's happening.

Upbound API unavailability blocks CI/CD pipelines that use up to deploy configurations, create MCPs, or query resource status. Pipelines fail with cryptic errors and there's no external signal that the API itself is the problem.

Configuration sync failures occur when a new Crossplane configuration package fails to install on an MCP. The MCP looks healthy, but the new provider or composite resource definitions never become available — silently breaking teams that expected the upgrade to land.

Marketplace API degradation affects teams pulling configurations from the Upbound Marketplace. Slow or unavailable marketplace endpoints cause up project build and package pulls to hang or timeout.

Step 1: Monitor the Upbound Cloud API

The Upbound Cloud API is the control plane for managing your MCPs. Monitor its availability directly:

# Check the Upbound Cloud API status endpoint
curl -s https://api.upbound.io/v1/health

Add this as a Vigilmon HTTP monitor:

  1. In the Vigilmon dashboard: Add Monitor → HTTP
  2. Configure:

| Field | Value | |---|---| | Name | Upbound Cloud API | | URL | https://api.upbound.io/v1/health | | Method | GET | | Expected status | 200 | | Check interval | 2 minutes | | Timeout | 15 seconds | | Alert after | 2 consecutive failures |

For the Upbound Marketplace API:

| Field | Value | |---|---| | Name | Upbound Marketplace API | | URL | https://marketplace.upbound.io/health | | Method | GET | | Expected status | 200 | | Check interval | 5 minutes | | Timeout | 15 seconds |

These monitors give you the first signal that Upbound platform issues are affecting your teams.

Step 2: Monitor Managed Control Plane API Endpoints

Each Upbound managed control plane exposes a Kubernetes API endpoint. Monitor its availability to know when an MCP is unreachable:

# Get your MCP's API endpoint
up controlplane get <your-mcp-name> -o json | jq '.status.controlPlaneURL'

Each MCP exposes a /healthz endpoint on its Kubernetes API:

# Check MCP Kubernetes API health
curl -sk https://<mcp-api-endpoint>/healthz \
  -H "Authorization: Bearer $(up ctx get-token)"

Add Vigilmon HTTP monitors for each MCP you run:

  1. Add Monitor → HTTP
  2. For each MCP:

| Field | Value | |---|---| | Name | MCP: <name> /healthz | | URL | https://<mcp-api-endpoint>/healthz | | Headers | Authorization: Bearer <token> | | Expected status | 200 | | Response body contains | ok | | Check interval | 1 minute | | Timeout | 10 seconds |

For long-lived tokens, rotate them periodically and update the Vigilmon monitor headers. For short-lived tokens, use a Vigilmon keyword monitor instead (Step 3).

Step 3: Heartbeat Monitor for MCP Reconciliation

An MCP that responds to /healthz might still have stalled reconciliation. Use a CronJob that runs up to verify actual provider health inside the MCP:

# upbound-mcp-probe-cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: upbound-mcp-reconcile-probe
  namespace: default
spec:
  schedule: "*/10 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: up-probe
              image: xpkg.upbound.io/upbound/up-cli:latest
              env:
                - name: UP_PROFILE
                  value: default
                - name: UPBOUND_TOKEN
                  valueFrom:
                    secretKeyRef:
                      name: upbound-credentials
                      key: token
                - name: MCP_NAME
                  value: production
                - name: ORG_NAME
                  value: your-org
                - name: HEARTBEAT_URL
                  valueFrom:
                    secretKeyRef:
                      name: vigilmon-secrets
                      key: upbound-mcp-heartbeat-url
              command:
                - /bin/sh
                - -c
                - |
                  set -e
                  # Authenticate with Upbound
                  up login --token "$UPBOUND_TOKEN"
                  # Check the MCP is running
                  STATUS=$(up controlplane get "$ORG_NAME/$MCP_NAME" \
                    -o json | jq -r '.status.phase')
                  if [ "$STATUS" != "Running" ]; then
                    echo "FAIL: MCP $MCP_NAME is in phase $STATUS"
                    exit 1
                  fi
                  # Check providers inside the MCP are healthy
                  up controlplane connect "$ORG_NAME/$MCP_NAME"
                  UNHEALTHY=$(kubectl get providers \
                    -o jsonpath='{range .items[*]}{.status.conditions[?(@.type=="Healthy")].status}{"\n"}{end}' \
                    | grep -c "False" || true)
                  if [ "$UNHEALTHY" -gt 0 ]; then
                    echo "FAIL: $UNHEALTHY providers unhealthy in MCP"
                    exit 1
                  fi
                  wget -qO- "$HEARTBEAT_URL"
                  echo "MCP reconciliation heartbeat sent"

Create the Vigilmon heartbeat monitor:

  1. Go to Add Monitor → Heartbeat
  2. Name: upbound MCP production reconciliation
  3. Expected interval: 10 minutes
  4. Grace period: 3 minutes
  5. Store the heartbeat URL:
kubectl create secret generic vigilmon-secrets \
  --from-literal=upbound-mcp-heartbeat-url='https://vigilmon.online/heartbeat/YOUR_TOKEN'

Step 4: Monitor Configuration Package Sync

Configuration package deployments are a common point of failure — a crossplane.io/v1.Configuration update might silently fail to install. Add a probe that verifies the latest configuration revision is healthy:

# upbound-config-sync-probe.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: upbound-config-sync-probe
  namespace: default
spec:
  schedule: "*/20 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: config-probe
              image: bitnami/kubectl:latest
              env:
                - name: HEARTBEAT_URL
                  valueFrom:
                    secretKeyRef:
                      name: vigilmon-secrets
                      key: upbound-config-sync-heartbeat-url
              command:
                - /bin/sh
                - -c
                - |
                  set -e
                  # Check all configurations are healthy
                  UNHEALTHY_CONFIGS=$(kubectl get configurations \
                    -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.status.conditions[?(@.type=="Healthy")].status}{"\n"}{end}' \
                    | grep -v "True" | wc -l)
                  if [ "$UNHEALTHY_CONFIGS" -gt 0 ]; then
                    echo "FAIL: $UNHEALTHY_CONFIGS configurations not healthy"
                    exit 1
                  fi
                  wget -qO- "$HEARTBEAT_URL"
                  echo "Config sync heartbeat sent"

This catches the common failure of a configuration upgrade that installs but leaves the package in Unhealthy state due to missing dependencies or version conflicts.

Step 5: Configure Alert Channels

Route Upbound alerts to the right teams:

  1. In Vigilmon: Alert Channels → Add Channel → Slack Webhook
  2. Add your #platform-alerts Slack webhook URL
  3. Assign to all MCP health and API monitors

For MCP downtime (which blocks all provisioning for affected teams), add PagerDuty:

  1. Alert Channels → Add Channel → PagerDuty
  2. Add your PagerDuty routing key
  3. Assign to MCP /healthz monitors only

For configuration sync failures (less urgent, but needs tracking), add email:

  1. Alert Channels → Add Channel → Email
  2. Add your platform team's email
  3. Assign to the config sync heartbeat monitor

What You're Now Monitoring

| Component | Monitor Type | What It Detects | |---|---|---| | Upbound Cloud API | HTTP | Platform API unavailability | | Upbound Marketplace API | HTTP | Marketplace degradation blocking package pulls | | MCP Kubernetes API | HTTP /healthz | Managed control plane unreachable | | MCP reconciliation | Heartbeat (10 min) | Providers stalled inside MCP | | Configuration sync | Heartbeat (20 min) | Package upgrade failures |

With these monitors in place, your platform team knows about Upbound failures before any developer's provisioning request times out.

Conclusion

Upbound's managed control plane model reduces operational burden, but it introduces a dependency on the Upbound Cloud platform itself that sits outside your cluster's observability stack. External monitoring with Vigilmon closes this blind spot — giving you the same external-perspective visibility for Upbound that you'd have for any critical SaaS dependency.

Get started free at vigilmon.online. Setting up the Upbound Cloud API monitor takes under two minutes, and the MCP heartbeat pattern scales to cover as many managed control planes as your organization runs.

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