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)
your service ──HTTP GET──▶ healthchecks.io/ping/[uuid]
(every N minutes)
if late ──▶ alertThe 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)
TunnelHQ check node ──WireGuard handshake──▶ your VPN server
(every 1 to 5 minutes by plan, from the general pool or the countries you choose)
if fail ──▶ alertThe 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
| Feature | 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 | 11 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 | 14 days free on every plan. Your card is charged on day 15, and you can cancel any time before. | 20 checks free forever (personal) |
| Lowest paid tier | $12 a month, 20 tunnels | $5/mo. 100 checks (Hobbyist) |
| 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. A typical 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.