Cloudflare Tunnel can report a healthy edge while the service behind it is silently broken. I built an autonomous sentinel that watches the origin, not the edge — and deliberately shipped it without write access until it earned trust.
Edge and tunnel status answer one question: is the tunnel connected? They do not answer the only question that matters — is the thing behind the tunnel actually alive?
A container reboots, DHCP hands it a new LAN IP, and the tunnel ingress still points at the old one. Now the edge serves errors — or worse, a different service — while every dashboard stays green. I call this the silent-origin-behind-healthy-edge class. Standard monitoring is structurally blind to it, because it probes the wrong layer.
The sentinel probes each origin LAN-side, bypassing Access, and classifies the real state before it touches anything. Only when a container's IP has genuinely drifted does it propose a Cloudflare ingress repoint.
Everything it learns is written to a machine-readable health.json, so the next automated agent — or a human — inherits ground truth instead of re-diagnosing from scratch.
OK
STALE_INGRESS_IP -> propose repoint
DEAD_ORIGIN
TUNNEL_DOWN
APP_UNHEALTHY
NEEDS_HUMANAuto-remediation that can rewrite production ingress is a loaded gun. The engineering here is mostly about not firing it:
health.json and writes zero Cloudflare changes. Write access is a later, earned phase — not day one.Two things I bring to infrastructure work: I find the failure classes your current monitoring can't see, and I build remediation that defaults to do no harm — staged rollouts, least-privilege tokens, isolated failure domains, and an architecture where the risky logic is the tested logic.
If you run agents, tunnels, or self-healing systems in production, that combination is the difference between automation you trust at 3am and automation you switch off after it burns you once.
Interested in this kind of work? Email is best — [email protected] · Back to portfolio