How to Monitor Nocalhost with Vigilmon (Dev Spaces, File Sync, and Remote Debug Health)

Nocalhost is a cloud-native Kubernetes development tool that lets engineers replace a running container in the cluster with a local development version — no image rebuilds, no redeployments. It manages dev spaces, coordinates file sync between local machines and pods, and exposes remote debug sessions that IDEs connect to over port-forwarding.

When Nocalhost's infrastructure components degrade, developers lose the ability to sync code changes, start debug sessions, or even enter dev mode. External monitoring catches these failures faster than teams scanning IDE error messages.

In this tutorial you'll set up uptime and availability monitoring for Nocalhost using Vigilmon — free tier, no credit card required.

What can go wrong in a Nocalhost deployment

Nocalhost has several distinct failure surfaces that are easy to miss:

• Nocalhost Server API down — the central server that manages dev space assignments and user authentication is unreachable; IDE plugins can't connect and show generic "server unavailable" errors
• Dev space controller stall — the Kubernetes controller responsible for injecting the dev container sidecar stops reconciling; nhctl dev start hangs indefinitely
• File sync daemon crash — the syncthing-based file sync process dies inside the container; code changes stop reaching the pod without any visible error in the IDE
• Remote debug port-forward broken — the port-forward that exposes the debugger port (e.g., 9229 for Node.js, 5005 for JVM) drops and the IDE debugger disconnects silently
• Container replace status stuck — the pod enters a ContainerReplacing state and never completes, blocking other developers from entering the same dev space

External monitoring gives you an independent signal for all of these, separate from IDE plugins and kubectl commands.

What you'll need

• A running Nocalhost Server (self-hosted via Helm or cloud-managed)
• The Nocalhost API endpoint accessible from outside the cluster
• A free Vigilmon account

Step 1: Identify your Nocalhost Server API endpoint

Nocalhost Server exposes a REST API. The base URL depends on how you deployed it:

# If deployed via Helm with an Ingress:
kubectl get ingress -n nocalhost

# Typical output:
# NAME               HOSTS                          ADDRESS
# nocalhost-web      nocalhost.example.com          1.2.3.4

Test the API health check endpoint:

curl -sf https://nocalhost.example.com/health | jq .

Expected response:

{
  "code": 0,
  "message": "success"
}

If you get a connection refused or non-200, check:

• The Nocalhost Server pod: kubectl get pods -n nocalhost
• The Ingress controller: kubectl get events -n nocalhost

Step 2: Add a dev space health probe

Nocalhost's built-in /health endpoint checks the server process but not the Kubernetes controller that manages dev spaces. Add a lightweight probe that verifies the controller is reconciling:

# nocalhost-health-probe.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: health-probe-script
  namespace: nocalhost
data:
  probe.sh: |
    #!/bin/sh
    # Check if nocalhost-dep controller pods are running
    READY=$(kubectl get deploy nocalhost-dep -n nocalhost \
      -o jsonpath='{.status.readyReplicas}' 2>/dev/null)
    if [ "$READY" -gt "0" ] 2>/dev/null; then
      echo '{"status":"ok","controller_replicas":'$READY'}'
      exit 0
    else
      echo '{"status":"degraded","controller_replicas":0}'
      exit 1
    fi

Alternatively, expose controller readiness via a simple sidecar HTTP server alongside the controller deployment. For most teams, monitoring the Nocalhost Server API plus the Kubernetes deployment readiness endpoint is sufficient.

Step 3: Create monitors in Vigilmon

Log into Vigilmon and add monitors for the critical Nocalhost components.

Monitor 1: Nocalhost Server API

Click Add Monitor and configure:

| Field | Value | |-------|-------| | Monitor type | HTTP(S) | | Name | Nocalhost Server API | | URL | https://nocalhost.example.com/health | | Check interval | 1 minute | | Expected status | 200 | | Alert threshold | 2 consecutive failures |

Monitor 2: Nocalhost web dashboard

The web dashboard is what developers use to manage dev spaces. It's served separately from the API:

| Field | Value | |-------|-------| | Monitor type | HTTP(S) | | Name | Nocalhost Web Dashboard | | URL | https://nocalhost.example.com/ | | Check interval | 2 minutes | | Expected status | 200 | | Expected keyword | nocalhost |

Monitor 3: Nocalhost API response latency

Dev space operations (entering dev mode, listing workloads) are latency-sensitive — developers expect near-instant responses from the IDE plugin.

1. Open the Nocalhost Server API monitor
2. Enable Response Time Tracking
3. Set Response Time Alert threshold to 1500ms

Step 4: Monitor the Nocalhost TCP endpoint

Nocalhost IDE plugins connect to the server API over port 443 (HTTPS). Add a TCP monitor as a network-layer check independent of the HTTP monitor:

| Field | Value | |-------|-------| | Monitor type | TCP | | Name | Nocalhost TCP Port | | Host | nocalhost.example.com | | Port | 443 | | Check interval | 1 minute |

This catches cases where TLS termination or the load balancer fails while the server pod itself appears healthy in kubectl.

Step 5: Monitor dev space file sync health

File sync in Nocalhost uses Syncthing running inside the dev container. If sync stalls, developers' code changes stop reaching the pod. You can expose a lightweight sync health endpoint from inside the dev container:

# Inside the dev container, Syncthing's local API runs on port 8384
# Add this to your devcontainer startup or sidecar:
curl -s http://localhost:8384/rest/system/ping \
  -H "X-API-Key: $SYNCTHING_API_KEY"

For external monitoring, expose this via a port-forwarded service or a dedicated health endpoint in your application that checks sync state:

// Express.js health route inside dev container
app.get('/sync-health', async (req, res) => {
  try {
    const syncStatus = await fetch('http://localhost:8384/rest/system/ping', {
      headers: { 'X-API-Key': process.env.SYNCTHING_API_KEY }
    });
    if (syncStatus.ok) {
      res.json({ sync: 'ok' });
    } else {
      res.status(503).json({ sync: 'degraded' });
    }
  } catch (err) {
    res.status(503).json({ sync: 'error', message: err.message });
  }
});

Monitor this endpoint via Vigilmon with a 2-minute interval.

Step 6: Configure alert routing

Go to Settings → Alerts in Vigilmon and route Nocalhost alerts to your development team's communication channels.

Slack notification

{
  "text": "🔴 Nocalhost {{monitor.name}} is DOWN\nDevelopers may be unable to start dev sessions.\nURL: {{monitor.url}}\nTime: {{alert.time}}"
}

Post to a #dev-platform-alerts channel so the platform team and affected developers both see the alert.

Email alert

Add individual developer email addresses or a team distribution list under Settings → Contacts in Vigilmon. Alert emails fire after your configured consecutive failure threshold.

Step 7: Create a developer platform status page

Platform teams maintaining Nocalhost for a development organization benefit from a shared status page developers can check before assuming their local environment is the problem.

In Vigilmon:

1. Go to Status Pages → New
2. Add all Nocalhost monitors
3. Title it "Developer Platform Status"
4. Share the URL in your team's onboarding documentation

This dramatically reduces "is Nocalhost down?" messages in Slack — developers check the status page first.

What to monitor: Nocalhost-specific checklist

| Component | Monitor type | Endpoint | |-----------|-------------|----------| | Nocalhost Server API | HTTP status | /health | | Web dashboard | HTTP keyword | / | | TCP port reachability | TCP | port 443 | | API response latency | HTTP with timing | /health | | Dev space file sync | HTTP status | app /sync-health | | Controller deployment | HTTP (via probe) | custom endpoint |

Common Nocalhost failure patterns

Server pod OOM killed: The Nocalhost Server API pod gets killed by the kubelet when memory pressure spikes on the node. The /health endpoint goes dark within seconds. Vigilmon fires after 2 consecutive check failures (~2 minutes).

Ingress certificate renewal: cert-manager renewing a TLS certificate can cause a brief nginx reload that drops active WebSocket connections between IDE plugins and the server. The TCP monitor catches port-level disruptions; the HTTP monitor catches if nginx fails to come back up correctly.

Database migration on upgrade: Upgrading the Nocalhost Server Helm chart runs schema migrations on startup. During migration, the API returns 503 for all requests. The HTTP monitor tracks this degradation window and fires if it exceeds your threshold (2 consecutive failures = ~2 minutes).

Syncthing state corruption: After a container crash, Syncthing's local state files can become corrupted. The sync health endpoint returns 503 while the main Nocalhost Server API appears healthy. Without a dedicated sync monitor, this failure is invisible until a developer notices their changes aren't appearing.

Summary

| What | Why | |------|-----| | /health HTTP monitor | Catches Nocalhost Server process failures | | Web dashboard keyword monitor | Confirms the UI is accessible to developers | | TCP monitor on 443 | Catches network/TLS failures upstream of the HTTP check | | Response time alert (1500ms) | Detects API slowdowns that degrade IDE plugin responsiveness | | Sync health endpoint monitor | Catches file sync daemon failures invisible to main health check | | Status page | Gives developers a self-service check before escalating to platform team |

Nocalhost failures silently block developer productivity — code changes don't sync, debug sessions disconnect, and dev containers stall in replacing state. Vigilmon's external monitoring gives your platform team an early warning signal before developers start reporting issues.

Sign up for Vigilmon free →