Cloudflare Tunnel still solves a real problem: you can publish internal or customer-facing services without exposing the origin directly to the public internet. A lightweight cloudflared process makes outbound-only connections to Cloudflare, which is why the model is attractive from a security perspective. The operational downside is that Tunnel also makes it very easy to accumulate one-off fixes: a connector for staging, a hostname added during a launch, a production dependency that “just works” but nobody owns. By June 2026, Cloudflare has improved Tunnel visibility enough that these gaps are no longer hard to see. That is good news for operations teams, and uncomfortable news for anyone sitting on undocumented tunnel sprawl.
For business owners and agency leads, the point is not technical neatness. It is risk control. If a client-facing service depends on a tunnel, you should be able to answer four basic questions quickly: what it routes, who owns it, how it fails over, and how it is troubleshot when it misbehaves. The 2026 updates make those answers easier to collect. They also make weak answers harder to excuse.
What improved in 2026
Three changes matter. On February 20, 2026, Cloudflare moved Tunnel into the main dashboard under Networking > Tunnels, with lifecycle management, tunnel health, replica visibility, and a routing map that shows public applications, private hostnames, private CIDRs, and Workers VPC services in one place. On March 19, 2026, Cloudflare added wrangler tunnel commands so teams can create, inspect, list, run, and delete tunnels from the terminal. On March 20, 2026, Cloudflare updated the Cloudflare One view so a tunnel’s overview page shows all active replicas and supports simultaneous log streaming from multiple replicas.
That combination matters because tunnel management is no longer buried in setup flows or scattered across copied UUIDs. In practice, the dashboard is now better for estate review, while the CLI is better for repeatable operations and handover. If your primary use case is securing origin servers and public applications, the main dashboard is the natural home. If your team works mainly inside Zero Trust access workflows, the Cloudflare One dashboard still matters. Either way, visibility is substantially better than it was at the start of the year.
What better visibility exposes
Most tunnel problems are ordinary rather than dramatic. A production hostname still resolves, but nobody knows which team owns the tunnel. A service that should survive a host failure actually depends on one healthy connector. DNS points to something sensible, but the origin mapping was set up in a rush and never reviewed. Agencies see a version of this all the time during client handover: the implementation works, but the operating model is trapped inside one person’s memory.
That is why observability matters here. Better visibility does not just help during incidents; it changes governance. Once you can review routes, health, and replicas centrally, “we are not really sure what is in use” stops sounding like a platform limitation and starts sounding like a management decision.
Keep the useful commands, but use them deliberately
The current Cloudflare docs still support a practical command set. For inventory and quick inspection, npx wrangler tunnel list and npx wrangler tunnel info <TUNNEL> are now genuinely useful. They make it easier to audit an account, compare what exists with what should exist, and produce documentation that someone else can actually follow. The important caveat is that Cloudflare still marks all wrangler tunnel commands as experimental, so if you build automation around them, pin versions and document the expected behavior.
For troubleshooting, remote log streaming is much better than “SSH into the box and hope.” Cloudflare’s current log docs confirm that you can stream logs from the dashboard or from a local machine with cloudflared installed. The core CLI patterns still worth keeping are cloudflared tail <UUID> and cloudflared tail --connector-id <CONNECTOR ID> <UUID> when you need one replica. If you want structured output, cloudflared tail --output=json <UUID> | jq . is still sensible. You can also reduce noise with filters such as --event, --level, and --sampling.
The limits matter just as much as the commands. Dashboard log streams only work for remotely managed tunnels, require edit permissions, and only help when the tunnel is active and receiving requests. Remote logging sessions are capped at one hour, and on high-throughput tunnels Cloudflare explicitly prioritizes service stability over perfect log delivery. If you need full coverage for audit or post-incident analysis, keep persistent server-side logs as well, for example with cloudflared tunnel --loglevel info --logfile cloudflared.log run <UUID> or the equivalent service configuration.
A rational Cloudflare Tunnel review
If you already rely on Tunnel, the smartest next step is usually rationalization, not expansion. A useful review should cover:
- Inventory: map each tunnel to its routes, related DNS, environment, origin service, and named owner.
- Resilience: check where a business-critical service is effectively hanging off one connector and decide whether more replicas are justified.
- Logging: define what must be persisted locally, what can be streamed remotely, and who is allowed to view sensitive logs.
- Lifecycle: decide which work belongs in the dashboard, which belongs in documented CLI procedures, and which should be API-driven.
- Handover: make sure an internal ops lead or a replacement agency can understand the setup without reverse-engineering it under pressure.
This is the commercial value of the 2026 improvements. Cloudflare has made Tunnel easier to see, easier to manage, and easier to troubleshoot. That does not remove the need for standards. It just means the standards can now be enforced with less friction.
If you want a cleaner operating model
If your team has several tunnels, uncertain ownership, or too much incident response by memory, it is probably time for a review. Greg can help turn a working-but-fragile tunnel estate into something documented, supportable, and easier to hand over. Start the conversation here.
Need help with this kind of work?
Discuss a Cloudflare Tunnel rationalization review Get in touch with Greg.