How to Monitor Weave Net with Vigilmon (HTTP + TCP + Alerts)

Weave Net is a Kubernetes CNI plugin that creates a virtual network connecting all containers across every node in your cluster — with optional in-flight encryption, multicast support, and a built-in network policy controller. The Weave Net daemon runs as a DaemonSet on every node, and its health directly determines whether cross-node pod networking is functional: a crashed or hung Weave Net process on even a single node makes all pods on that node unreachable from the rest of the cluster. Vigilmon adds the external perspective that Weave Net cannot provide for itself: continuous uptime and latency checks from outside your infrastructure that keep watching even when the network component itself is the failure. You can add your first monitor for free, no credit card required.

Why Weave Net needs external monitoring

DaemonSet crash on a node isolates all pods running there. Weave Net runs as a privileged DaemonSet pod on every cluster node. If the Weave Net container exits unexpectedly — due to an OOM kill, a kernel module failure, or a segfault in the VXLAN datapath — all pods on that node lose network connectivity to the rest of the cluster. Kubernetes does not immediately reschedule the DaemonSet pod; there is a backoff period, and during that window the node is effectively network-partitioned. An external HTTP monitor that probes the Weave Net status API detects this failure mode because the Weave Net HTTP status port becomes unreachable when the daemon is down.
VXLAN datapath failures allow pods to start but drop all traffic silently. Weave Net's VXLAN encapsulation layer uses kernel networking APIs to forward cross-node traffic. If the host kernel's VXLAN module is unloaded, or if iptables rules are corrupted by a concurrent CNI plugin operation, Weave Net may continue to report itself as healthy while silently dropping all inter-node packets. Pods start and pass Kubernetes readiness probes (which probe localhost) but fail to communicate with pods on other nodes. An external connectivity check from Vigilmon targeting a known cluster endpoint over the Weave network detects this class of packet-drop failure that internal health probes miss entirely.
Fast datapath OVS integration failures degrade throughput without crashing. Weave Net can use the Linux Open vSwitch fast datapath for higher throughput. If the OVS integration breaks — due to a kernel upgrade, a missing module, or a configuration drift — Weave Net falls back to the slower userspace datapath transparently without surfacing an error. Pod connectivity is preserved but throughput drops significantly, causing latency spikes in services that have large inter-pod traffic volumes. An external HTTP monitor on the Weave Net status endpoint can detect the fallback because the status API reports the active datapath mode.
IP address pool exhaustion prevents new pods from scheduling. Weave Net manages its own IP allocation across the cluster using a distributed algorithm that partitions the configured CIDR range among nodes. If the IP pool for a node is exhausted — because many pods have been created and their IP release has been delayed by a crash loop or a lingering network namespace — new pod scheduling fails with IP allocation errors. The Weave Net status API exposes IP space metrics, and an external monitor that checks the status endpoint can surface pool exhaustion before it causes Failed to allocate IP scheduling failures at scale.
Network policy controller divergence allows forbidden traffic. Weave Net includes an optional network policy controller that programs iptables rules to enforce Kubernetes NetworkPolicy objects. If the controller's watch connection to the Kubernetes API server drops and is not re-established — due to a network partition between the node and the control plane — it stops learning about new or updated NetworkPolicy resources. Existing policies continue to be enforced, but new policies are silently ignored, creating a security gap where newly denied traffic is permitted. An external monitor on the Weave Net status endpoint detects stale policy controller state when the status API reports the last-synced policy timestamp.

What you'll need

A running Weave Net installation with its HTTP status port accessible
The public hostname or IP for a node running Weave Net, for example https://weave-node.example.com
A free Vigilmon account — monitors start running in under a minute with no credit card required

Step 1: Expose Weave Net's status endpoint

Weave Net exposes an HTTP status endpoint on port 6784 by default. Verify it is reachable before configuring Vigilmon monitors.

# Check Weave Net status on a node (run from inside the cluster or via node access)
curl http://<node-ip>:6784/status

# Sample output:
# {
#   "Version": "2.8.1",
#   "Router": {
#     "Name": "a2:b4:c6:d8:e0:f2",
#     "NickName": "node1",
#     "Peers": [...],
#     "TrustedSubnets": [],
#     "ProtocolVersion": 2
#   },
#   "IPAM": {
#     "Status": "ready",
#     "Range": "10.32.0.0/12",
#     ...
#   },
#   "DNS": {...},
#   "Proxy": {...}
# }

# Check which pods are healthy on the DaemonSet
kubectl get pods -n kube-system -l name=weave-net -o wide

# Check Weave Net pod logs on a specific node
kubectl logs -n kube-system -l name=weave-net -c weave --tail=50

# Verify the weave network interface exists on a node
ip link show weave

If Weave Net is deployed with an Ingress or NodePort exposing the status endpoint externally:

# Check the Weave Net DaemonSet port configuration
kubectl get daemonset -n kube-system weave-net -o jsonpath='{.spec.template.spec.containers[0].ports}' | jq .

# Test the status endpoint via NodePort if exposed
curl http://<node-external-ip>:<nodeport>/status

# Check connectivity across nodes using Weave's built-in connectivity check
kubectl exec -n kube-system -it <weave-pod-name> -c weave -- /home/weave/weave --local status connections

Step 2: Set up HTTP monitoring in Vigilmon

Add an HTTP monitor for the Weave Net status endpoint:

Log in to vigilmon.online and click Add Monitor.
Set Monitor type to HTTP.
Enter the URL: http://weave-node.example.com:6784/status
Set Check interval to 60 seconds and Expected status code to 200.
Click Save Monitor — Vigilmon will run the first check within a minute.

Add a monitor for the Weave Net metrics endpoint

Weave Net exposes Prometheus metrics on port 6782 that reflect the health of the overlay network in more detail:

Click Add Monitor again.
Set Monitor type to HTTP.
Enter the URL: http://weave-node.example.com:6782/metrics
Set Expected status code to 200 and Timeout to 10 seconds.
Set a Response time threshold of 3000ms to detect VXLAN datapath slowdowns before they cascade to application latency.
Click Save Monitor.

Why external monitoring catches what internal checks miss

Weave Net is a foundational layer of Kubernetes cluster networking. When a Weave Net daemon crashes or the VXLAN datapath becomes corrupted, Kubernetes' own control-plane monitoring — liveness probes, readiness probes, node conditions — either takes seconds to minutes to reflect the failure, or misses it entirely because probes that run on localhost bypass the broken network overlay. Vigilmon operates entirely outside your infrastructure, probing Weave Net from external network vantage points on a fixed interval. It is the earliest warning system for cross-node networking failures before application health checks and on-call pages begin cascading.

Step 3: Monitor Weave Net's TCP port

A TCP monitor confirms that the Weave Net status HTTP server is accepting connections at the network layer before any HTTP processing begins. This catches scenarios where the Weave Net container is stuck during initialization or has crashed but the node itself remains reachable.

In Vigilmon, click Add Monitor.
Set Monitor type to TCP.
Enter Host: weave-node.example.com and Port: 6784.
Set Check interval to 60 seconds.
Click Save Monitor.

If Weave Net exposes an external HTTPS endpoint via an Ingress:

# Find all ports exposed by the Weave Net DaemonSet
kubectl get daemonset -n kube-system weave-net \
  -o jsonpath='{.spec.template.spec.containers[*].ports}' | jq .

# Sample output:
# [
#   {"containerPort": 6784, "name": "status",    "protocol": "TCP"},
#   {"containerPort": 6782, "name": "metrics",   "protocol": "TCP"},
#   {"containerPort": 6783, "name": "control",   "protocol": "TCP"}
# ]

Add a TCP monitor for port 6783 (the Weave Net control plane port) to independently confirm that the mesh overlay control channel is accepting connections, separate from the status HTTP layer.

Step 4: Configure alert channels

Email alerts

In Vigilmon, go to Alert Channels and click Add Channel.
Choose Email and enter the address that should receive notifications (for example, network-team@example.com or an on-call distribution list).
Assign this channel to all Weave Net monitors created in Steps 2 and 3.
Click Save — Vigilmon will send a test email to confirm delivery.

Webhook alerts

For Slack, PagerDuty, or an internal incident management system, add a webhook channel:

In Alert Channels, click Add Channel and choose Webhook.
Paste your endpoint URL (a Slack incoming webhook, PagerDuty Events API v2 endpoint, or custom URL).
Vigilmon will POST the following JSON payload when a monitor transitions to down:

{
  "monitor_id": "mon_weavenet_status",
  "monitor_name": "Weave Net /status",
  "status": "down",
  "previous_status": "up",
  "checked_at": "2026-07-12T09:14:22Z",
  "response_time_ms": null,
  "status_code": null,
  "error": "Connection refused",
  "url": "http://weave-node.example.com:6784/status"
}

Assign all Weave Net monitors to this channel and click Save.

Runbook: diagnostics to run when an alert fires

#!/bin/bash
# Weave Net alert runbook — run these in order when Vigilmon fires

echo "=== DaemonSet status ==="
kubectl get daemonset -n kube-system weave-net

echo "=== Pod status per node ==="
kubectl get pods -n kube-system -l name=weave-net -o wide

echo "=== Recent events ==="
kubectl get events -n kube-system --sort-by='.lastTimestamp' | grep -i weave | tail -20

echo "=== Status endpoint response ==="
curl -sv http://weave-node.example.com:6784/status 2>&1 | tail -30

echo "=== Weave Net peer connections ==="
kubectl exec -n kube-system daemonset/weave-net -c weave -- \
  /home/weave/weave --local status connections 2>/dev/null | head -20

echo "=== IPAM status ==="
kubectl exec -n kube-system daemonset/weave-net -c weave -- \
  /home/weave/weave --local status ipam 2>/dev/null

echo "=== Port connectivity ==="
nc -zv weave-node.example.com 6784
nc -zv weave-node.example.com 6782

echo "=== Network interface check ==="
ip link show weave 2>/dev/null || echo "Weave interface not found"

echo "=== Weave Net container logs (last 100 lines) ==="
kubectl logs -n kube-system daemonset/weave-net -c weave --tail=100

echo "=== Node conditions ==="
kubectl describe nodes | grep -A5 "Conditions:"

echo "=== Test cross-node pod connectivity ==="
kubectl run net-test --image=busybox --rm -it --restart=Never \
  -- ping -c 3 <pod-on-another-node-ip> 2>&1 | head -10

Step 5: Create a public status page

A Vigilmon status page gives your platform engineering team and application developers a single URL to check Weave Net health during incidents — no cluster access required.

In Vigilmon, navigate to Status Pages and click New Status Page.
Give it a name such as Weave Net Network and choose a subdomain like weave-net-status.vigilmon.page.
Add all monitors created in this tutorial: the /status HTTP monitor, the /metrics HTTP monitor, and the TCP port monitor.
Optionally add a description explaining that Weave Net is the cluster overlay network and that downtime affects cross-node pod communication.
Click Publish — the page is immediately accessible and updates in real time.

Share this URL in your team's incident response runbook and link it from your developer platform documentation. When engineers see connection refused or timeout errors between pods on different nodes, the status page is the first place to check whether Weave Net is healthy.

Putting it all together

| Monitor | Type | What it catches | |---|---|---| | http://weave-node.example.com:6784/status | HTTP | DaemonSet crash, VXLAN datapath failure, IPAM exhaustion, policy drift | | http://weave-node.example.com:6782/metrics | HTTP | Metrics endpoint failure, performance degradation, datapath slowdowns | | weave-node.example.com:6784 | TCP | Network-level connectivity loss, status server crash, node unreachability |

# Quick-reference diagnostic one-liners when a Vigilmon alert fires

# 1. Are Weave Net pods running on all nodes?
kubectl get pods -n kube-system -l name=weave-net -o wide

# 2. Is the status endpoint responding?
curl -sf http://weave-node.example.com:6784/status || echo "Status check FAILED"

# 3. Are all peers connected?
kubectl exec -n kube-system daemonset/weave-net -c weave -- \
  /home/weave/weave --local status connections | grep -c "established"

# 4. What is the IPAM state?
kubectl exec -n kube-system daemonset/weave-net -c weave -- \
  /home/weave/weave --local status ipam

# 5. Is port 6784 open?
nc -zv weave-node.example.com 6784 && echo "Port open" || echo "Port CLOSED"

# 6. Are there any recent error events?
kubectl get events -n kube-system | grep -i "weave\|network" | tail -10

# 7. Check weave interface on node
ip -4 addr show weave

# 8. Run a cross-node connectivity test
kubectl run ping-test --image=busybox --rm -it --restart=Never \
  -- ping -c 3 <remote-pod-ip>

What's next

SSL certificate monitoring — If you expose Weave Net's status or metrics endpoints via HTTPS, Vigilmon can alert you days before the TLS certificate expires. Add an SSL monitor pointing at the same hostname to avoid unexpected TLS failures that break your monitoring pipeline.
Heartbeat monitoring for network policy sync — Configure a Kubernetes CronJob that verifies a known NetworkPolicy rule is being enforced (by testing a blocked connection), then POSTs a heartbeat to a Vigilmon dead-man's-switch endpoint. If the network policy controller stops processing policies, the heartbeat stops and Vigilmon fires an alert before unauthorized cross-pod traffic becomes a security incident.
Latency trend monitoring — Use Vigilmon's response time history to establish a latency baseline for the Weave Net status endpoint. Gradual latency increases on the status port often indicate that the Weave Net daemon is under memory pressure or that the VXLAN datapath is degrading, giving you time to investigate and potentially restart affected DaemonSet pods before cross-node latency causes application SLA breaches.

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