How to Monitor jsPolicy with Vigilmon (HTTP + TCP + Alerts)

jsPolicy is a JavaScript-based Kubernetes admission policy engine that lets platform teams write, test, and enforce admission policies using familiar JavaScript and TypeScript — no Rego or CEL required. Its webhook server is the enforcement point for every resource creation and modification event in your cluster: if jsPolicy goes down or becomes unresponsive, Kubernetes' admission control chain is blocked and all resource operations that match a policy stall or fail, halting deployments across the cluster. Vigilmon adds the external perspective that jsPolicy cannot provide for itself: continuous uptime and latency checks from outside your infrastructure that keep watching even when the policy engine is the component that has failed. You can add your first monitor for free, no credit card required.

Why jsPolicy needs external monitoring

Webhook server crash blocks all admission-controlled resource operations. jsPolicy registers itself as a Kubernetes ValidatingWebhookConfiguration and MutatingWebhookConfiguration. Every resource create, update, and delete that matches a policy triggers a synchronous call to the jsPolicy webhook server. If the webhook server process crashes, Kubernetes cannot reach the admission endpoint and begins returning webhook-related errors for all matching operations. Unless the webhook is configured with failurePolicy: Ignore, all affected resource types — Pods, Deployments, ConfigMaps — become impossible to create or update until jsPolicy is restored.
Policy compilation errors after a hot reload freeze the enforcement pipeline. jsPolicy supports live policy updates by watching PolicyException and JsPolicy resources in the cluster and recompiling the JavaScript policy bundles on change. If a policy update introduces a syntax error, an unresolved import, or an infinite loop in compilation, the recompilation goroutine can panic or deadlock, leaving jsPolicy serving stale compiled policies or rejecting all admission requests with internal errors. The process remains alive but enforcement behavior is undefined. An external HTTP health monitor detects this class of failure because the health endpoint reflects the state of the policy runtime, not just the process.
TLS certificate expiry on the webhook endpoint breaks admission control cluster-wide. Kubernetes API server validates the TLS certificate presented by admission webhook servers using the CA bundle registered in the WebhookConfiguration. If the jsPolicy webhook server's TLS certificate expires, the Kubernetes API server rejects the TLS handshake and marks the admission webhook as failed. Depending on the failure policy, this either causes all matching admission requests to be rejected or silently allowed, neither of which is correct. An external SSL monitor gives you advance warning of expiry before it triggers a cluster-wide admission control failure.
JavaScript sandbox exhaustion degrades policy evaluation latency cluster-wide. jsPolicy uses a V8 JavaScript engine sandbox to evaluate policies. Under high admission request rates — during deployments, canary rollouts, or cluster-wide rollouts — the sandbox pool can become exhausted, causing policy evaluations to queue. Kubernetes has a default admission webhook timeout of 30 seconds; if jsPolicy cannot evaluate a policy in time, the request times out and is rejected (with failurePolicy: Fail) or allowed (with failurePolicy: Ignore). An external HTTP monitor with a response time threshold set below the Kubernetes admission webhook timeout detects sandbox saturation before it triggers resource creation failures.
CRD controller reconciliation failures allow policy bypasses to go undetected. jsPolicy runs a controller that watches JsPolicy and JsPolicyException CRDs and reconciles the WebhookConfiguration to match the current policy set. If the controller's watch connection to the API server drops — due to a network partition, certificate expiry on the in-cluster service account, or an RBAC change — new policies and exceptions are not applied and deleted policies are not removed. The webhook server continues enforcing the last-known policy set indefinitely. There is no internal alert for this drift state, but an external monitor on the health endpoint that validates policy sync status can surface it.

What you'll need

A running jsPolicy instance with its webhook server accessible over HTTPS
The public hostname or IP for your jsPolicy deployment, for example https://jspolicy.example.com
A free Vigilmon account — monitors start running in under a minute with no credit card required

Step 1: Expose jsPolicy's health endpoint

Verify your jsPolicy installation is reachable and locate the health endpoint before configuring Vigilmon monitors.

# Check jsPolicy webhook server health endpoint
curl -I https://jspolicy.example.com/healthz

# Sample output:
# HTTP/2 200
# content-type: application/json
# x-jspolicy-version: 0.2.2

# Verify the readiness endpoint
curl -I https://jspolicy.example.com/readyz
# Expected: HTTP/2 200

# Check that the webhook server is registered in Kubernetes
kubectl get validatingwebhookconfigurations | grep jspolicy
kubectl get mutatingwebhookconfigurations | grep jspolicy

If jsPolicy is deployed in Kubernetes (the standard installation method), verify the Deployment and Service are healthy:

# Check jsPolicy deployment
kubectl get deployment -n jspolicy jspolicy

# Expected:
# NAME       READY   UP-TO-DATE   AVAILABLE
# jspolicy   2/2     2            2

# Check pod status
kubectl get pods -n jspolicy -o wide

# Test from inside the cluster
kubectl run tmp-curl --image=curlimages/curl --rm -it --restart=Never \
  --namespace=jspolicy -- \
  curl -sk https://jspolicy.jspolicy.svc.cluster.local/healthz

Verify the webhook server's TLS certificate is valid and check its expiry:

# Check TLS certificate details
echo | openssl s_client -connect jspolicy.example.com:443 \
  -servername jspolicy.example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates

# Verify the CA bundle registered in Kubernetes matches the cert
kubectl get validatingwebhookconfigurations jspolicy -o jsonpath='{.webhooks[0].clientConfig.caBundle}' \
  | base64 -d | openssl x509 -noout -subject

Step 2: Set up HTTP monitoring in Vigilmon

Add an HTTP monitor for the jsPolicy health endpoint:

Log in to vigilmon.online and click Add Monitor.
Set Monitor type to HTTP.
Enter the URL: https://jspolicy.example.com/healthz
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 jsPolicy readiness endpoint

The readiness endpoint reflects whether jsPolicy is ready to handle admission requests — a critical distinction from liveness:

Click Add Monitor again.
Set Monitor type to HTTP.
Enter the URL: https://jspolicy.example.com/readyz
Set Expected status code to 200 and Timeout to 10 seconds.
Set a Response time threshold of 5000ms to detect admission pipeline saturation before Kubernetes webhook timeouts trigger.
Click Save Monitor.

Why external monitoring catches what internal checks miss

jsPolicy sits in the critical path of every Kubernetes admission operation. When it fails, the symptoms are resource creation and update errors throughout the cluster — not a monitoring dashboard alert. Internal Kubernetes health probes check whether the jsPolicy pod is running and whether it returns liveness from inside the cluster network — but they cannot detect whether the V8 sandbox pool is saturated, whether policy compilation has panicked, or whether TLS certificates are approaching expiry. Vigilmon operates entirely outside your infrastructure, probing jsPolicy from external network vantage points on a fixed interval with response time threshold monitoring. It is the earliest warning system for admission pipeline degradation before deployments start failing.

Step 3: Monitor jsPolicy's TCP port

A TCP monitor confirms that the jsPolicy webhook server is accepting connections at the network layer before TLS or HTTP processing begins. This catches scenarios where the TLS listener has crashed but the container remains alive, or where a Kubernetes Service has lost its endpoint backing after a rollout.

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

If your jsPolicy deployment exposes the webhook on its default port 9443 separately from an external HTTPS proxy, add a second TCP monitor:

# Find the ports jsPolicy is listening on
kubectl get pod -n jspolicy -l app=jspolicy \
  -o jsonpath='{.items[0].spec.containers[0].ports}' | jq .

# Sample output:
# [
#   {"containerPort": 9443, "name": "webhook", "protocol": "TCP"},
#   {"containerPort": 8080, "name": "metrics",  "protocol": "TCP"}
# ]

Add a TCP monitor for port 9443 (webhook) to directly confirm the admission controller port is open, independent of any proxy or Ingress 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, platform-team@example.com or an on-call distribution list).
Assign this channel to all jsPolicy 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_jspolicy_healthz",
  "monitor_name": "jsPolicy /healthz",
  "status": "down",
  "previous_status": "up",
  "checked_at": "2026-07-12T09:14:22Z",
  "response_time_ms": null,
  "status_code": null,
  "error": "Connection refused",
  "url": "https://jspolicy.example.com/healthz"
}

Assign all jsPolicy monitors to this channel and click Save.

Runbook: diagnostics to run when an alert fires

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

echo "=== Deployment status ==="
kubectl get deployment -n jspolicy jspolicy

echo "=== Pod status ==="
kubectl get pods -n jspolicy -o wide

echo "=== Recent events ==="
kubectl get events -n jspolicy --sort-by='.lastTimestamp' | tail -20

echo "=== Health endpoint response ==="
curl -sv https://jspolicy.example.com/healthz 2>&1 | tail -20

echo "=== Readiness endpoint response ==="
curl -sv https://jspolicy.example.com/readyz 2>&1 | tail -10

echo "=== Webhook configuration status ==="
kubectl get validatingwebhookconfigurations jspolicy -o yaml | grep -A5 "failurePolicy"
kubectl get mutatingwebhookconfigurations jspolicy -o yaml | grep -A5 "failurePolicy"

echo "=== Port connectivity ==="
nc -zv jspolicy.example.com 443

echo "=== TLS certificate expiry ==="
echo | openssl s_client -connect jspolicy.example.com:443 \
  -servername jspolicy.example.com 2>/dev/null \
  | openssl x509 -noout -enddate

echo "=== jsPolicy logs (last 100 lines) ==="
kubectl logs -n jspolicy -l app=jspolicy --tail=100

echo "=== Policy status ==="
kubectl get jspolicy -A
kubectl get jspolicyviolation -A | tail -20

echo "=== Test a simple admission request ==="
kubectl run admission-test --image=nginx --dry-run=server -o yaml 2>&1 | head -20

Step 5: Create a public status page

A Vigilmon status page gives your platform engineering team and any teams that deploy to Kubernetes a single URL to check jsPolicy health during incidents — no cluster access required.

In Vigilmon, navigate to Status Pages and click New Status Page.
Give it a name such as jsPolicy Admission Control and choose a subdomain like jspolicy-status.vigilmon.page.
Add all monitors created in this tutorial: the /healthz HTTP monitor, the /readyz HTTP monitor, and the TCP port monitor.
Optionally add a description explaining that jsPolicy is the admission control layer for the cluster and that downtime affects all resource operations.
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 admission webhook denied errors in their CI pipelines, the status page is the first place to check whether jsPolicy is healthy.

Putting it all together

| Monitor | Type | What it catches | |---|---|---| | https://jspolicy.example.com/healthz | HTTP | Process crash, policy compilation panic, runtime failure, TLS expiry | | https://jspolicy.example.com/readyz | HTTP | Admission pipeline saturation, V8 sandbox exhaustion, startup delays | | jspolicy.example.com:443 | TCP | Network-level connectivity loss, TLS listener crash, Service endpoint loss |

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

# 1. Are jsPolicy pods running?
kubectl get pods -n jspolicy -l app=jspolicy -o wide

# 2. Are there recent errors in the policy engine?
kubectl logs -n jspolicy -l app=jspolicy --tail=50

# 3. Can the health endpoint be reached?
curl -sf https://jspolicy.example.com/healthz || echo "Health check FAILED"

# 4. Is the readiness endpoint returning OK?
curl -sf https://jspolicy.example.com/readyz || echo "Not ready"

# 5. Is port 443 open?
nc -zv jspolicy.example.com 443 && echo "Port open" || echo "Port CLOSED"

# 6. How long until the TLS cert expires?
echo | openssl s_client -connect jspolicy.example.com:443 \
  -servername jspolicy.example.com 2>/dev/null \
  | openssl x509 -noout -enddate

# 7. Are any policies currently in violation?
kubectl get jspolicyviolation -A --no-headers | wc -l

# 8. Can you run a dry-run admission request?
kubectl run test-pod --image=nginx --dry-run=server 2>&1 | head -5

What's next

SSL certificate monitoring — Vigilmon can alert you days before the TLS certificate on jspolicy.example.com expires, giving you time to renew before the Kubernetes API server begins rejecting webhook TLS handshakes and blocking cluster-wide admission control. Add an SSL monitor pointing at the same hostname.
Heartbeat monitoring for policy reconciliation — Configure a cron job that applies a synthetic test JsPolicy resource to the cluster and verifies that jsPolicy successfully reconciles it into the WebhookConfiguration, then POSTs a heartbeat to a Vigilmon dead-man's-switch endpoint. If the reconciliation pipeline stops sending heartbeats, Vigilmon fires an alert indicating policy drift between the desired and enforced state.
Latency trend monitoring — Use Vigilmon's response time history to establish a latency baseline for the /healthz and /readyz endpoints. Sudden latency increases on the readiness endpoint often indicate V8 sandbox pool saturation or policy evaluation queue growth and give you time to scale the jsPolicy Deployment before Kubernetes webhook timeouts start rejecting cluster operations.

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