Rancher Desktop is an open-source desktop application that brings local Kubernetes and container management to macOS, Windows, and Linux. It bundles containerd, dockerd, and k3s (a lightweight Kubernetes distribution) into a single app — giving developers a full container and Kubernetes stack without needing to manage individual components.
But a local Kubernetes cluster is still a Kubernetes cluster: pods crash, services lose their endpoints, and ingresses silently fail. When you're running shared development or staging clusters on Rancher Desktop, external monitoring catches failures that kubectl get pods won't surface until you look. This tutorial shows you how to connect Vigilmon to your Rancher Desktop services.
Why monitor Rancher Desktop services?
Rancher Desktop makes it easy to spin up local Kubernetes workloads, but "easy to start" doesn't mean "easy to observe":
- Pod crash loops — a pod restarts every 30 seconds, appears
Running, but never serves traffic - Service endpoint failures — the Kubernetes Service exists but all backing pods are unscheduled or unhealthy
- Ingress misconfigurations — a route is defined in your ingress but the upstream service is unreachable
- Node resource pressure — the Rancher Desktop VM runs out of memory or CPU and all workloads degrade together
- Namespace drift — a teammate deletes a deployment or changes a ConfigMap, silently breaking dependent services
External HTTP and TCP monitoring from Vigilmon verifies that your services are reachable and responsive from outside the Rancher Desktop VM — the same signal your users would experience.
What you'll need
- A service running in Rancher Desktop with an exposed NodePort, LoadBalancer, or port-forwarded endpoint
- A free Vigilmon account
Step 1: Deploy a service with a health endpoint
Before setting up monitoring, deploy a workload that exposes a /health route. Here's a minimal example:
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: nginx:alpine
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 3
periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
name: api
namespace: default
spec:
selector:
app: api
type: NodePort
ports:
- port: 80
targetPort: 80
nodePort: 30080
Apply it:
kubectl apply -f deployment.yaml
Verify the service is running:
kubectl get pods,svc -n default
# NAME READY STATUS RESTARTS AGE
# pod/api-5d9b4c8f7-x9kl2 1/1 Running 0 30s
#
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
# service/api NodePort 10.43.12.200 <none> 80:30080/TCP 30s
Access it at http://localhost:30080/health (Rancher Desktop exposes NodePort services on localhost).
Step 2: Expose the service for external monitoring
Vigilmon monitors from external regions, so localhost won't work directly. You have two options:
Option A: Port-forward to a public host
If you're running Rancher Desktop on a VPS or a machine with a public IP, the NodePort is directly reachable at http://<your-public-ip>:30080.
Option B: Use ngrok for local testing For laptop-based development:
ngrok http 30080
# Forwarding: https://abc123.ngrok.io -> http://localhost:30080
Use the ngrok HTTPS URL as your Vigilmon monitor target.
Step 3: Set up HTTP monitoring in Vigilmon
- Log in to vigilmon.online and go to Monitors → New Monitor
- Choose HTTP / HTTPS
- Enter your service URL, e.g.
http://203.0.113.42:30080/health - Set the check interval to 1 minute
- Configure Expected response:
- Status code:
200
- Status code:
- Save the monitor
Vigilmon will now probe your Rancher Desktop service from multiple regions every minute.
Step 4: Add TCP port monitoring
For services that don't speak HTTP — a PostgreSQL pod, a Redis StatefulSet, or a gRPC server — add TCP monitors:
- Go to Monitors → New Monitor
- Choose TCP Port
- Enter your host and port, e.g.
203.0.113.42/30432 - Save
Common Kubernetes TCP services and their typical NodePorts:
| Service | Container Port | Example NodePort | |---|---|---| | PostgreSQL | 5432 | 30432 | | Redis | 6379 | 30679 | | MySQL | 3306 | 30306 |
Step 5: Key metrics to watch
For Rancher Desktop Kubernetes clusters, focus on:
| Metric | What it catches | |---|---| | HTTP uptime | Pod crashes, readiness failures, ingress breakage | | HTTP response time | Node resource pressure, slow startup | | TCP port reachability | Service endpoint loss, NodePort failures | | Response body content | Silent application-level failures |
Vigilmon's response time history lets you see if your cluster is under memory pressure — response times will creep up before pods start crashing.
Step 6: Configure alerts
- Go to Alert Channels → Add Channel
- Choose Webhook for Slack, Discord, or PagerDuty, or Email for simpler setups
- Paste your webhook URL
- Assign the channel to your Rancher Desktop monitors
- Set alert trigger: after 1 failed check
For a shared development environment, route alerts to your team's #dev-alerts Slack channel so everyone knows when the cluster is unhealthy.
Step 7: Create a status page for your local cluster
If your team shares a Rancher Desktop cluster for integration testing, a status page gives everyone a single source of truth:
- Go to Status Pages → New Status Page
- Name it, e.g. "Local K8s Status"
- Add your HTTP and TCP monitors
- Publish the page and share the URL in your team Slack
Monitoring with kubectl readiness probes vs. Vigilmon
It's worth understanding the difference:
| | kubectl / liveness probes | Vigilmon | |---|---|---| | Scope | Inside the cluster | External, multi-region | | What it checks | Pod health | User-facing endpoint reachability | | Alerts | Restart policy only | Instant webhook/email alert | | History | No retention | Full response-time history | | Status page | No | Yes |
Kubernetes liveness and readiness probes keep pods cycling. Vigilmon tells you when users can't reach your service — even when all pods say Running.
Putting it all together
A production-ready Rancher Desktop monitoring setup:
# 1. Deploy workloads with readiness probes
kubectl apply -f deployment.yaml
# 2. Verify NodePort is accessible
curl http://localhost:30080/health
# 3. In Vigilmon: create HTTP monitor on http://<host>:30080/health
# 4. In Vigilmon: create TCP monitor on <host>:30432 for the database
# 5. In Vigilmon: create Slack alert channel, assign to both monitors
# 6. In Vigilmon: publish status page, share URL with team
Conclusion
Rancher Desktop puts a full Kubernetes cluster on your laptop or VPS — but running containers at scale introduces failure modes that kubectl get pods doesn't surface until you look. Vigilmon adds the external, user-facing layer of observability that Kubernetes-native health checks leave out: continuous probing from multiple regions, instant alerts, and a public status page your team can bookmark. Set it up once and you'll know about cluster outages before your users do.