WasmWorkers Server (WWJS) brings a Cloudflare Workers-style programming model to your own infrastructure, running JavaScript and WebAssembly workloads inside a lightweight Wasm sandbox. Because WWJS workers are isolated per-request, a misconfigured module, a broken dynamic import, or a missing key-value binding can fail silently — returning a 200 while serving degraded output. Vigilmon provides external, synthetic health probes that catch these failures before your users notice.
This tutorial walks through instrumenting a WasmWorkers Server application for production-grade monitoring.
What You'll Build
- A
/healthworker endpoint that verifies runtime dependencies - A Vigilmon HTTP monitor targeting your WWJS health route
- Heartbeat monitoring for scheduled WWJS tasks
- Alert channels (email + webhook) configured in Vigilmon
Prerequisites
- WasmWorkers Server running (self-hosted via Docker or binary)
- A worker registered and serving traffic
- A free account at vigilmon.online
Step 1: Add a Health Worker to WasmWorkers Server
WWJS workers are JavaScript modules that export a fetch handler. Create a dedicated health worker that tests your real runtime dependencies.
health.js
// health.js — register this worker at route /health
export default {
async fetch(request, env) {
const checks = {};
let ok = true;
// Cache/KV probe (if using WWJS key-value bindings)
if (env.KV) {
try {
await env.KV.put("__health_probe__", "1", { expirationTtl: 60 });
const val = await env.KV.get("__health_probe__");
checks.kv = val === "1" ? "ok" : "read_mismatch";
if (checks.kv !== "ok") ok = false;
} catch (err) {
checks.kv = `error: ${err.message}`;
ok = false;
}
}
// Upstream service probe
try {
const resp = await fetch("https://api.example.com/ping", {
signal: AbortSignal.timeout(3000),
});
checks.upstream = resp.ok ? "ok" : `http_${resp.status}`;
if (!resp.ok) ok = false;
} catch (err) {
checks.upstream = `timeout_or_error`;
ok = false;
}
// Worker runtime self-check
checks.runtime = "ok";
return Response.json(
{ status: ok ? "ok" : "degraded", checks, ts: Date.now() },
{ status: ok ? 200 : 503 }
);
},
};
Register the health worker
In your WWJS configuration, register the worker at the /health route:
{
"workers": [
{
"name": "health",
"script": "./health.js",
"routes": ["/health"]
}
]
}
Or, if you use the WWJS CLI:
wwjs worker add health ./health.js --route /health
Verify locally:
curl http://localhost:7654/health
# {"status":"ok","checks":{"kv":"ok","upstream":"ok","runtime":"ok"},"ts":1720000000000}
Step 2: Add a Vigilmon HTTP Monitor
- Log in to Vigilmon and click Add Monitor → HTTP.
- Set URL to
https://<your-wwjs-host>/health. - Set Check interval to 60 seconds.
- Set Expected status code to
200. - Under Advanced, enable JSON body assertion:
- Path:
status - Expected value:
ok
- Path:
- Save. Vigilmon alerts you the instant your WWJS health worker returns non-200 or
degraded.
Alert channels
Go to Alerts → Add channel:
- Email — immediate on-call notification
- Webhook — Slack, PagerDuty, or any HTTP endpoint
Step 3: Heartbeat Monitoring for Scheduled Workers
WWJS supports cron-style scheduled workers. If a scheduled worker fails silently (exception caught internally, job skipped), you won't see it in request logs. Vigilmon heartbeats catch this.
Add a heartbeat ping at the end of each successful scheduled run:
// scheduled-job.js
export default {
async scheduled(event, env, ctx) {
try {
await runYourJob(env);
// Notify Vigilmon on success
await fetch("https://vigilmon.online/api/heartbeat/<your-heartbeat-id>", {
method: "POST",
});
} catch (err) {
// Do NOT ping on failure — Vigilmon will fire an alert after grace period
console.error("Scheduled job failed:", err);
}
},
};
In Vigilmon, create a Heartbeat monitor with a grace period of 1.5× your scheduled interval. A missed heartbeat triggers an immediate alert.
Step 4: Protecting the Health Endpoint
If your WWJS instance is publicly accessible, protect the /health endpoint with a shared secret so it isn't abused by third parties:
export default {
async fetch(request, env) {
const token = request.headers.get("X-Health-Token");
if (token !== env.HEALTH_TOKEN) {
return new Response("Unauthorized", { status: 401 });
}
// ... health checks
},
};
In Vigilmon, add a Custom header to the monitor:
- Name:
X-Health-Token - Value: your shared secret
Step 5: Key Metrics to Alert On
| Metric | What it signals | Vigilmon check |
|---|---|---|
| /health returns 5xx | Worker runtime error or crash | HTTP status assertion |
| /health returns degraded | KV or upstream dependency broken | JSON body assertion |
| Response time > 1 s | Wasm module cold-start or I/O hang | Response time threshold |
| Heartbeat missing | Scheduled worker stalled | Heartbeat grace period |
| Intermittent 503 | WWJS process restart or OOM | HTTP status + alert frequency |
Step 6: Status Page
Create a Vigilmon status page to give users real-time visibility into your WWJS service. Go to Status Pages → Create, add your health monitor, and embed the badge:
<img src="https://vigilmon.online/badge/<monitor-id>.svg" alt="Service Status" />
What You Get
| Scenario | How Vigilmon catches it |
|---|---|
| Worker module fails to load | HTTP monitor sees 5xx, fires alert |
| KV binding misconfigured | /health returns degraded |
| Upstream API goes down | Dependency check in health worker fails |
| Scheduled job stops running | Heartbeat not received in grace period |
| WWJS process crashes and restarts | HTTP monitor detects downtime gap |
WasmWorkers Server gives you edge-grade isolation on your own infrastructure — but self-hosted means you own the reliability story. Vigilmon provides the external monitoring layer that tells you when your WWJS service is unhealthy, even when internal logs look clean.
Start monitoring your WasmWorkers Server today — register free at vigilmon.online.