Scaling Tail for Production-Grade Workers
Real-time visibility into applications running in production is one of the most effective debugging tools a developer can have. Local tests and automated checks only go so far — when users start reporting issues, the ability to see exactly what requests are doing in the moment is often what makes the difference between a quick fix and a long investigation.
That’s the problem Cloudflare’s Workers Tail was built to solve. It streams live request, exception, and log data from Workers to tools like the Cloudflare dashboard and the Wrangler CLI. The feature itself was built on Workers technology, using Trace Workers and Durable Objects for message coordination. But as usage grew, so did the demands on that architecture.
Tail was initially capped at 100 requests per second (RPS) per Worker. High-traffic applications simply couldn’t be tailed without overwhelming the Durable Object handling message coordination. Teams running large Workers had to build their own observability tooling to get the same insight. That limitation is now gone: Tail can be enabled for Workers at any scale, thanks to a series of architectural changes designed to keep the underlying system stable under load.
The bottleneck: a single point of coordination
The original Tail design used Durable Objects to coordinate message flow between the Worker being tailed and the consumer — whether that was Wrangler or the dashboard. Durable Objects are well suited to real-time coordination, but they have limits when a single instance is hit with a very high volume of traffic. Since high-traffic Workers could easily exceed what a single Durable Object could handle, Tail was restricted to Workers under the 100 RPS threshold.
To fix this, the team made three key changes: moving filtering upstream, adding sampling, and introducing a failsafe to prevent Durable Object overload.
Filtering moves closer to the source
Tail has always allowed users to filter messages based on request or log attributes. In the original design, that filtering was performed inside the Durable Object itself. That meant every message had to reach the Durable Object before being evaluated — even if a filter would discard the vast majority of them. Users with high traffic who relied heavily on filters to make sense of their logs were often still blocked by the 100 RPS ceiling.
The fix was to move filtering out of the Durable Object and into the Tail message producer. Now, filtered messages never reach the Durable Object at all, which directly reduces the load on that coordination point. It was the first and most straightforward step toward scaling Tail.
Sampling keeps traffic within safe bounds
Filtering helps, but it doesn’t solve the case where a Worker simply generates more legitimate traffic than a Durable Object can handle. And since it’s impossible to know in advance how much a filter will reduce traffic for a given Tail, there was no reliable way to predict whether starting a new Tail would push the Durable Object past its limit.
The solution is a simple controller that tracks the RPS hitting the Durable Object and samples messages as needed to keep the volume at or below the 100 RPS target. When sampling kicks in, users see a notification every five seconds indicating that they are in sampling mode. The message disappears when the Tail is stopped, or once filters bring the RPS below the threshold.
Sampling ensures that even the busiest Workers can be tailed — users just see a representative subset of traffic rather than every single message. To demonstrate, here’s what happens to a high-traffic tail as RPS climbs:
Sampling relies on RPS tracking within the Durable Object. If traffic spikes so fast that the Durable Object becomes overloaded before sampling can respond, the mechanism itself fails. As a last line of defense, a separate failsafe detects that overload condition and periodically stops forwarding all messages to the Durable Object, preventing any impact on the broader Workers infrastructure.
The behavior is visible in practice: as a user’s traffic increases, more messages get sampled. If the traffic rate outpaces the sampling mechanism, the Durable Object can briefly become overloaded. Once the failsafe engages and excess messages are blocked, the overload clears and normal (or sampled) operation resumes.
Available now
The improved Tail is live for all users today. To start tailing from the dashboard, navigate to your Worker and open the Logs tab, where you can start a log stream from the default view. From the command line, simply run wrangler tail.
Beyond live logs
Tail gives you a live window into your Worker, but it’s not the only observability option. For teams that need historical log data or want to route events to external destinations, Cloudflare offers Logpush for pushing logs to storage and analytics services. For deeper control over log messages and events themselves, Tail Workers can be used to intercept and process log streams programmatically.
