Why We Run Our Own Pinger Network Instead of Serverless

Every uptime tool eventually answers the same question: where do the checks actually run? The fashionable answer is "serverless" — Lambda, Cloudflare Workers, whatever scales to zero and bills by the millisecond. We evaluated it. We run dedicated probe nodes instead. This is why.

The checks that don't fit a function

Our check types tell the story. ICMP ping needs raw sockets — not available in any mainstream FaaS runtime. DNSBL lookups are IP-reputation sensitive: query Spamhaus from a shared NAT pool and you get rate-limited or blocked outright, because a thousand other tenants are hammering the same zones. SSH and SFTP login checks need real TCP connections with real handshake timing — not a proxied dialer. Game-server queries (A2S, Minecraft status ping) are UDP with protocol-specific payloads.

A function that can only do HTTP probes is a monitoring product that can only check websites. That is not what we sell.

Stable egress IPs are a feature, not a constraint

Probe nodes have public, stable IPs. That means:

• You can allowlist them. Customers with firewalled endpoints (internal tools exposed to "the internet but only from these IPs") get real monitoring instead of workarounds.
• DNSBL queries actually work. Our probe IPs have clean reputation and sane query rates — results reflect your listing status, not our IP pool's.
• Checks are attributable. When a customer's IDS alerts on our SSH login probe, the source IP is documented, not a random AWS exit node.

With serverless, egress IPs are shared, ephemeral and mostly unknown. For a monitoring product, that's disqualifying.

Latency you can actually measure

A pinger node on Hetzner in Falkenstein checking a host in the same region reports real network latency. A Lambda cold-starting in eu-central-1 reports Lambda cold-start latency plus network latency. When a customer's alert threshold is 800ms, the difference between 15ms of probe overhead and 300ms of it is the difference between a signal and noise.

The cost math is boring, and that's the point

A CPX-class node runs tens of thousands of checks per minute and costs single-digit euros a month. The equivalent serverless invocation volume costs more, does less, and comes with per-request pricing anxiety every time we add a check type. Our bill is predictable; our checks aren't metered.

What we gave up

Honesty matters: serverless would have given us instant global scale-out and zero node management. We pay for our choice with real ops work — node provisioning, OPNsense gateways, failover between probe regions. But the product promise is "checks that behave like the network actually behaves," and that promise has to be kept by infrastructure we control. A check we can't fully control is a result we can't stand behind.

If you're evaluating monitoring tools, ask where the checks run. If the answer is "a function somewhere," ask what happens when you need to ping an IP, query a blocklist, or log into an SSH server.