TunnelHQ vs Healthchecks.io
Healthchecks.io and TunnelHQ use opposite monitoring models. Healthchecks.io is heartbeat-based — your service pings their endpoint on schedule, and if the ping is late, you get alerted. TunnelHQ is probe-based — it actively reaches out to your VPN servers, performs the protocol handshake, and alerts on the result. Both are valid; they catch different failure modes.
TL;DR
Pick Healthchecks.io if: you want to monitor scheduled jobs, cron tasks, batch processes, or long-running services that can ping an endpoint when they're alive. Especially good for backups, ETL jobs, and dead-man's-switch patterns.
Pick TunnelHQ if: you want to monitor VPN server availability from outside — you don't control the VPN server's ability to self-report, you need to see what a real client sees, and you need protocol-aware handshake validation.
The models side by side
Healthchecks.io (pull / heartbeat)
The service is responsible for proving it's alive. Healthchecks.io sits passive, waiting for pings. Missed ping = alert. Excellent for confirming that a backup actually ran, a cron actually executed, a long-lived job is still running.
TunnelHQ (push / probe)
The monitoring service initiates. The target can be completely passive — in fact, it shouldn't know it's being checked. Good for external services, VPN servers, APIs your customers consume.
Feature comparison
| TunnelHQ | Healthchecks.io | |
|---|---|---|
| Model | Active probe from check nodes | Passive heartbeat (service pings in) |
| Good for | External-facing services — VPN, API, web | Internal jobs — cron, batch, background workers |
| VPN protocol handshakes | 10+ protocols native | Not applicable (service would ping HC from inside the VPN server, which proves only that something is running) |
| Sees what users see? | Yes — probes from outside | No — only knows whether the service pinged |
| Requires code changes? | No — just paste the config | Yes — add a ping step to your service |
| Detects "process running but not working" | Yes — handshake fails even if process is up | Partial — depends on where ping is wired in the job |
| Free tier | 5 monitors, 10-min interval | 20 checks free forever (personal) |
| Lowest paid tier | $12/mo — 20 monitors | $5/mo — 100 checks (Hobbyist) |
| Status pages | Included | Included |
| REST API | 30–120 req/min by plan | Yes; documented |
| Self-hostable | No (commercial SaaS) | Yes — open source (BSD-3-Clause) |
When to use each
Use Healthchecks.io for
- Cron jobs — confirm they actually ran
- Nightly backups — dead-man's-switch alert if they don't complete
- Long-running ETL pipelines — heartbeat at each stage
- Message queue workers — prove they're still consuming
- Internal batch processes not exposed to the internet
Use TunnelHQ for
- VPN servers — real protocol handshake, external vantage
- V2Ray/Xray servers with subscription URLs
- Verifying what your users actually experience
- Catching "process is running but tunnel is broken" failures
- Compliance audit trails showing external availability
The obvious combination
Many teams run both. Example setup:
- Healthchecks.io: wraps the nightly cron that rotates VPN configs and re-seeds the subscription URL — if the cron doesn't ping within the window, alert.
- TunnelHQ: continuously monitors the VPN servers themselves from outside — catches when a server silently dies between rotations, or when the subscription URL returns stale configs.
The two tools cover different failure modes. They don't compete.