tutorial

Monitoring Radius with Vigilmon: API Server Health, Dashboard Availability, and Application Deployment Checks

How to monitor Radius with Vigilmon — API server health, dashboard availability, application deployment endpoint checks, and SSL certificate alerts.

Radius is a Microsoft-backed, CNCF-incubated cloud-native application platform that lets developers define, deploy, and connect cloud-native applications using a consistent abstraction layer across Azure, AWS, Kubernetes, and on-premises environments. Platform teams rely on Radius's control plane — the rad CLI, the Radius API server, and the Dashboard — to model applications, provision environments, and connect resources like databases, message queues, and secrets vaults. When the Radius API server is unreachable, engineers cannot deploy or update applications. When the Dashboard is down, operator visibility disappears. When SSL certificates expire, rad CLI commands fail. Vigilmon gives you external, agent-free visibility into every Radius availability surface.

What You'll Build

  • An HTTP monitor on the Radius API server health endpoint to detect control plane failures
  • A Dashboard availability check to confirm the web UI is accessible
  • A TCP port monitor on the Radius API port for low-level connectivity checks
  • SSL certificate monitoring for your Radius installation domain
  • An alerting setup that separates API failures from Dashboard rendering issues

Prerequisites

  • A running Radius installation (v0.21+) with an accessible API server and Dashboard
  • HTTPS configured for your Radius endpoint (e.g., https://radius.example.com)
  • A free account at vigilmon.online

Step 1: Understand Radius's Health Endpoints

The Radius API server exposes a liveness probe that reports the control plane status. You can probe it directly:

curl https://radius.example.com/healthz
# Returns: {"status":"OK"}

For a readiness check that verifies the Radius API can reach the Kubernetes API server:

curl https://radius.example.com/apis/api.radius.dev/v1alpha3/

A healthy API server returns HTTP 200. If the Radius control plane is down, you receive a connection refused or a 502/503 from the ingress controller in front of it. The Dashboard is a separate process — it can be up while the API is down, and vice versa.

Step 2: Create a Vigilmon HTTP Monitor for the API Server

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://radius.example.com/healthz.
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: OK (present in the health response body).
  7. Click Save.

This monitor catches:

  • Radius API server pod crashes or OOM kills
  • Kubernetes namespace evictions that take down Radius control plane pods
  • Radius upgrade failures that leave the API server in a broken state
  • Ingress controller misconfigurations that block access to the Radius service
  • Control plane connectivity issues preventing Radius from reaching the Kubernetes API

Alert sensitivity: Trigger after 1 consecutive failure. When the Radius API server is down, no application deployments can proceed and environment provisioning stops entirely.

Step 3: Monitor the Radius Dashboard

The Radius Dashboard provides the web-based UI for visualizing application graphs, environment configurations, and resource connections. Platform teams use it to inspect application topology and debug connection failures. Dashboard availability is a separate failure surface from API health:

curl https://radius.example.com
# Returns HTML with "Radius" in the page content
  1. Add Monitor → HTTP.
  2. URL: https://radius.example.com (or your dedicated Dashboard URL if separate).
  3. Check interval: 2 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: Radius (present in the Dashboard HTML).
  7. Label: Radius Dashboard.
  8. Click Save.

When the Dashboard monitor fires but the /healthz monitor stays green, the problem is specific to the Dashboard process — typically a static asset serving failure, a frontend build issue, or a proxy configuration problem — not the API control plane.

Step 4: Monitor the Radius API Port via TCP Check

The rad CLI and Radius control plane components communicate with the API server over HTTPS. A TCP-level check confirms the port is accepting connections independently of HTTP-layer health:

nc -zv radius.example.com 443

If you expose the Radius API on a non-443 port (common in Kubernetes clusters that use NodePort or a dedicated LoadBalancer service):

  1. Add Monitor → TCP.
  2. Host: radius.example.com.
  3. Port: 443 (or your custom API port).
  4. Check interval: 2 minutes.
  5. Label: Radius API TCP.
  6. Click Save.

TCP checks catch ingress TLS termination failures and load balancer routing problems that HTTP-layer monitors may miss when the ingress itself returns a 200 from a cached error page.

Step 5: Monitor SSL Certificates

The rad CLI validates TLS certificates on every command. An expired certificate breaks all rad commands — deployments, environment inspections, and rad run — for every developer in your organization simultaneously:

openssl s_client -connect radius.example.com:443 2>/dev/null | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: radius.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Radius is often deployed inside a corporate Kubernetes cluster using internal CAs or cert-manager with Let's Encrypt. Internal CA certificates have longer lifetimes but are often renewed manually. A 30-day alert window gives platform teams time to act before engineers start seeing x509: certificate has expired errors in rad CLI output.

Step 6: Monitor the Radius Environment API Endpoint

Radius environments are namespaced groupings of recipes and infrastructure definitions. If the environments API returns errors, developers cannot deploy into named environments — a specific failure mode that doesn't necessarily bring down the entire health endpoint:

curl -s https://radius.example.com/apis/api.radius.dev/v1alpha3/namespaces/default/environments \
  -H "Authorization: Bearer $RADIUS_TOKEN" | jq '.kind'
# Returns: "EnvironmentList"
  1. Add Monitor → HTTP.
  2. URL: https://radius.example.com/apis/api.radius.dev/v1alpha3/namespaces/default/environments.
  3. Check interval: 5 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: EnvironmentList.
  7. Label: Radius Environments API.
  8. Click Save.

Step 7: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | /healthz API | Non-200 or keyword missing | Check Radius control plane pods: kubectl get pods -n radius-system | | Dashboard | Non-200 or keyword missing | Dashboard process failure; check Dashboard pod logs | | API TCP port | Connection refused | Load balancer or ingress failure; check service endpoints | | SSL certificate | < 30 days to expiry | Renew certificate; check cert-manager or internal CA | | Environments API | Non-200 or keyword missing | Kubernetes API server connectivity issue; check RBAC and CRDs |

Alert after: 1 consecutive failure for the API health and TCP monitors. 2 consecutive failures for the Dashboard and environment endpoint monitors.

Common Radius Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Radius API server pod OOM killed | /healthz returns connection error; alert within 60 s | | Dashboard process crash | Dashboard monitor fires; API health stays green | | Kubernetes API server degraded | Environments API fails; control plane operations stop | | Ingress controller upgrade breaks routing | All monitors fire simultaneously | | SSL certificate expires | SSL monitor alerts; rad CLI fails for all developers | | CRD version mismatch after Radius upgrade | API health may be green; specific resource APIs return 404 or 500 | | LoadBalancer IP changes after cloud rebalancing | TCP and HTTP monitors fail; DNS needs updating | | Namespace RBAC change blocks Radius service account | Environments API returns 403; deployments fail |

Radius is the control plane that lets your developers describe cloud-native applications once and deploy them anywhere — Azure, AWS, Kubernetes, or on-prem. When the Radius API server or Dashboard fails, your entire application platform becomes invisible. Vigilmon gives you continuous external visibility into every layer: API health, Dashboard availability, port connectivity, environment endpoints, and SSL certificate expiry, so you catch control plane failures before they block your development teams.

Start monitoring Radius 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