How to Monitor Okteto Development Environments with Vigilmon

Okteto turns your Kubernetes cluster into a cloud development platform — developers spin up full-stack environments in seconds, iterate on code with live reload, and tear everything down when they're done. But when those environments host long-running preview services, shared staging APIs, or persistent preview URLs that stakeholders rely on, you need more than Kubernetes health probes.

In this tutorial you'll set up external uptime monitoring for your Okteto environments using Vigilmon — free tier, no credit card required.

Why Okteto environments need external monitoring

Okteto's built-in tooling tells you whether a dev environment is running. It does not tell you whether it is reachable from the outside world. The gap matters more than it sounds:

• Ingress routing failures — Okteto provisions per-environment ingress rules. When an ingress controller update changes annotation handling, pods stay Running while URLs silently 404
• TLS certificate issues — each environment gets a wildcard subdomain. Certificate renewal failures leave URLs unreachable without any error in okteto status
• Namespace-level quota exhaustion — resource limits can starve a service without terminating the pod; it shows as healthy but returns 503
• Preview environment drift — a shared preview URL your QA team or product stakeholders are checking may degrade between deployments without anyone noticing
• Persistent staging services — teams that run staging on Okteto need the same reliability guarantees as production

Vigilmon monitors these environments from multiple geographic regions, independent of Okteto's own observability. If the URL goes down for any reason, you know within a minute.

What you'll need

• An Okteto Cloud account or self-hosted Okteto instance
• A deployed application with an accessible URL (Okteto gives you a URL like https://my-app-namespace.cloud.okteto.net)
• A free Vigilmon account (sign up takes 30 seconds)

Step 1: Deploy your application and verify the URL

Start by deploying your application to Okteto and confirming it has a public URL.

A typical okteto.yml for a Node.js service looks like this:

# okteto.yml
name: my-api
image: node:18-alpine
command:
  - node
  - src/index.js
workdir: /app
environment:
  - NODE_ENV=development
  - PORT=3000
forward:
  - 3000:3000

Deploy it:

okteto up

For persistent deployments (not just dev sessions), use an Okteto Pipeline or okteto deploy:

# okteto-pipeline.yml
deploy:
  - kubectl apply -f k8s/

okteto deploy

Once deployed, check the external URL:

okteto endpoints
# NAME     URL
# my-api   https://my-api-myteam.cloud.okteto.net

Add a /health endpoint to your application so Vigilmon has a clean signal to probe:

// Express.js example
app.get('/health', (req, res) => {
  res.json({ status: 'ok', env: process.env.NODE_ENV, ts: new Date().toISOString() });
});

Verify it responds:

curl https://my-api-myteam.cloud.okteto.net/health
# {"status":"ok","env":"development","ts":"2024-01-15T10:23:00Z"}

Step 2: Set up HTTP monitoring in Vigilmon

With your Okteto URL verified, add it to Vigilmon:

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS as the monitor type
3. Set the URL to your Okteto endpoint: https://my-api-myteam.cloud.okteto.net/health
4. Set the check interval to 1 minute
5. Under Expected response:
   • Status code: 200
   • (Optional) Response body contains: "status":"ok"
6. Save the monitor

Vigilmon will immediately begin probing your endpoint from multiple geographic regions. If any region detects a failure, it cross-checks with the others before triggering an alert — so you don't get paged for a single-region network blip.

Setting up monitors for multiple environments

If your team runs multiple Okteto environments (one per feature branch, for example), you can monitor each one separately:

| Environment | URL Pattern | Monitor Name | |-------------|-------------|--------------| | main branch | https://my-api-team.cloud.okteto.net/health | okteto/main | | feature/auth | https://my-api-feature-auth-team.cloud.okteto.net/health | okteto/feature-auth | | staging | https://my-api-staging-team.cloud.okteto.net/health | okteto/staging |

Create a separate Vigilmon monitor for each environment that needs uptime guarantees.

Step 3: Monitor the underlying TCP connectivity

HTTP monitoring catches application-level failures. TCP monitoring catches lower-level issues — port binding failures, load balancer routing problems, and network policy changes that prevent traffic from reaching the pod.

Okteto environments expose ports through Kubernetes services. If you know the underlying node IP and service port, add a TCP monitor:

1. In Vigilmon, go to Monitors → New Monitor
2. Choose TCP Port
3. Enter the host (your Okteto subdomain works here too) and port 443
4. Save the monitor

This catches TLS termination failures and port-level connectivity issues that HTTP monitors might miss if the TCP handshake fails before the HTTP layer responds.

Step 4: Configure alert channels

When an Okteto environment goes down, your team needs to know immediately — not when a developer asks "why isn't staging working?"

Email alerts

1. In Vigilmon, go to Alert Channels → Add Channel → Email
2. Add your team's engineering email address
3. Assign the channel to your Okteto monitors

Webhook alerts for Slack or Teams

1. Go to Alert Channels → Add Channel → Webhook
2. Enter your Slack or Teams incoming webhook URL
3. Assign the channel to your Okteto monitors

Vigilmon sends a payload like this when a monitor goes down:

{
  "monitor_name": "okteto/staging /health",
  "status": "down",
  "url": "https://my-api-staging-team.cloud.okteto.net/health",
  "started_at": "2024-01-15T10:23:00Z",
  "duration_seconds": 90
}

You can use this webhook payload to trigger automatic actions — for example, redeploying the environment via the Okteto CLI:

# Triggered by webhook handler
okteto deploy --namespace myteam-staging

Diagnosing Okteto failures when alerts fire

When Vigilmon alerts you that an Okteto endpoint is down, use this diagnostic sequence:

# Check the environment status
okteto status

# Check pod health in the namespace
kubectl get pods -n myteam

# Check the ingress rules
kubectl get ingress -n myteam

# Check ingress controller logs
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail=50

# Test connectivity from inside the cluster
kubectl run tmp-curl --image=curlimages/curl --rm -it --restart=Never \
  -n myteam -- curl http://my-api:3000/health

If the in-cluster curl works but Vigilmon shows the URL as down, the issue is in the ingress layer — routing rules, TLS, or the Okteto ingress controller itself.

Step 5: TLS certificate monitoring

Okteto uses wildcard certificates for its subdomains. If you're running a self-hosted Okteto instance, you manage your own TLS — and certificate expiry is a silent failure mode that Kubernetes won't warn you about.

Vigilmon monitors SSL certificate expiry automatically when you set up an HTTPS monitor. You'll receive an alert:

• 30 days before expiry — enough time to renew manually if cert-manager fails
• 7 days before expiry — urgent warning
• On expiry — the monitor will start reporting failures if your TLS certificate lapses

For self-hosted Okteto, cert-manager typically handles renewal. But cert-manager can fail silently — wrong solver configuration, ACME rate limits, or DNS validation failures. Vigilmon's cert expiry monitoring is your safety net.

Step 6: Create a status page for your preview environments

If QA, product managers, or external stakeholders check preview environments, give them a status page instead of fielding "is the staging URL down?" questions.

1. In Vigilmon, go to Status Pages → New Status Page
2. Name it: "Okteto Preview Environments"
3. Add your monitors organized by team or feature:
   • Core Services: main branch API, staging API
   • Active Features: feature-auth, feature-payments
4. Publish the page

You get a public URL like https://status.vigilmon.online/your-page that your whole team can bookmark. When something is down, they can check the status page before filing a ticket.

Putting it all together

Here's a recommended monitoring setup for a typical Okteto deployment:

| Monitor | Type | What it catches | |---------|------|-----------------| | https://my-api-team.cloud.okteto.net/health | HTTP | App crashes, ingress routing failures, DNS issues | | https://my-api-staging-team.cloud.okteto.net/health | HTTP | Staging environment health | | my-api-team.cloud.okteto.net:443 | TCP | TLS port binding and load balancer routing |

What's next

• Heartbeat monitoring — if your Okteto environment runs scheduled jobs or background workers, Vigilmon's heartbeat monitors alert you when they stop reporting in
• Multi-environment strategy — use Vigilmon monitor groups to organize monitors by team, project, or environment type
• CI/CD integration — pause monitors during planned deployments and resume them automatically when your pipeline finishes, avoiding false alerts during rolling updates

Get started free at vigilmon.online — no credit card, monitors start running in under a minute.