Gateway & Health Check
What is Health Check?
Health Check lets WinWraper automatically verify that your service is actually working correctly, not just "the process is running" but that it is responding normally.
WinWraper calls an HTTP endpoint of your service every 10 seconds to confirm liveness.
Health column in the Service List
| Status | Colour | Meaning |
|---|---|---|
| Healthy | Green ✓ | Service returned HTTP 200 |
| Unhealthy | Red ✗ | Endpoint didn't respond or returned an error |
| Unknown | Grey, | No URL configured or not enough data yet |
How a Health Check URL gets configured
The current WinWraper release does not expose a UI for users to enter a Health Check URL manually. The URL is assigned automatically only for services WinWraper installs through ⚡ Quick Add, today that means the OpenClaw Gateway, which is wired up to http://127.0.0.1:<port>/healthz.
Services you add manually via ➕ Add Service will show Health status Unknown and WinWraper will not perform HTTP polling for them.
💡Tip
Many web frameworks already include a /healthz or /health endpoint. If yours doesn't, add a simple route that returns {"status":"ok"} with HTTP 200, ready for when WinWraper adds a Health Check UI in a future update.
Health Check with OpenClaw (WSL2 Gateway)
The OpenClaw service (the AI gateway running inside WSL2) behaves differently: instead of HTTP polling, WinWraper checks health based on the Windows process state of the gateway.
The reason: OpenClaw can be busy processing AI requests and may not respond to HTTP in time, using HTTP polling would produce false "Unhealthy" alerts.
See: WSL2 & OpenClaw
Using Health Check effectively
| Situation | Recommendation |
|---|---|
| Web service (Node.js, Python Flask, ...) | Add a /healthz route that returns 200 |
| Background worker with no HTTP interface | Skip Health Check, use Watcher to monitor instead |
| Service that depends on a database | The /healthz route should check the DB connection and return 503 if the DB is offline |
Next: WSL2 & OpenClaw →