Catching an anomaly in live application traffic still means tailing a log file, running regex searches, or shipping data to a separate SIEM for analysis. That model is valuable for post-incident review, but it makes it hard for an operator to decide within seconds while a problem is actually happening. In cases of attack, latency spikes or incorrect blocking, delayed visibility is a direct operational risk.
Bulk log systems typically do not carry the full context of every request. Headers, cookies, body fields, WAAP score breakdown, country, ASN, user identity, routed backend and response time may not appear on the same line. An operator trying to understand why a request was blocked or why it was routed differently must stitch together fragments from separate systems.
Aggregate dashboards are not sufficient on their own either. Average response time, total request count or overall error rate show that a problem exists, but they do not directly reveal which path, which user, which country, which source IP or which WAAP rule is responsible. The journey from event to rule therefore turns into manual analysis, retesting and trial and error.
The right approach is to show the live stream at the request level and present each request alongside the variables the platform used to make its decision. Operators should be able to choose the variables they want to track, pause the stream, replay recent events and move from a specific request into rule creation without leaving the screen.
TR7 Live Traffic Tracking closes this gap: it turns live traffic from data that is merely observed into an operational signal that can be acted on immediately.
TR7 designs live traffic tracking as an operational bridge connecting real-time delivery, unified stat collection, FX variable visibility and rule generation.
Other on-prem ADC and WAAP products require a separate management VM or central controller platform to be deployed and operated for this depth of live analysis. TR7 Live Traffic Tracking runs in the operator console on the same appliance that serves the traffic — no second platform to license, size or run.
Operators subscribe to a live stream by selecting the pool, update interval and filter. The system pushes data to the client at the specified interval — no continuous query loop is needed on the operator side.
Statistics from Layer 7 and Layer 4 pools flow into the same live tracking model. Operators do not need to learn separate screens or separate monitoring logic for different traffic types.
The full TR7 variable catalogue — request, response, user, security and network context — is available in the live tracking view. Operators select, filter and group only the variables they need rather than showing everything at once.
Any request visible in the live table can serve as the starting point for a new traffic or security rule. Path, source IP, country, user, WAAP score or header values are carried into the rule editor pre-filled, ready for the operator to refine and save.
Live Traffic Tracking makes production traffic visible through selectable variables and connects observation directly to operational action.
Operators select the pool they want to monitor and set the live update interval. The interval is adjustable from 1 to 60 seconds; the default is 5 seconds. This model supports controlled monitoring in high-traffic environments as well as closer tracking for lower-volume services. The live stream is started and managed based on the state of the selected pool.
The live table can show request line, headers, cookies, body fields, response code, response time, backend name, WAAP score, country, ASN and user context — among more than 200 available variables. Operators select only the variables they need to keep the table focused. This approach provides purpose-specific visibility instead of showing everything at once. The table can be oriented toward security, performance or user context depending on the problem at hand.
The live stream can be narrowed with a filter so that only specific field sets or requests matching certain conditions are surfaced. Operators can focus on path, status code, WAAP score, country, source IP or user identity. This keeps the table readable under high traffic load and reduces unnecessary data transfer. The monitoring view stays a decision-support panel rather than turning into a log dump.
Operators can pause the live stream and review recent events held in the client-side replay buffer. This is especially useful for fast-moving WAAP blocks, sudden latency spikes or isolated suspicious requests. Events that occurred before the stream was paused can be analysed in the table without waiting for the same request to reappear.
From a selected request, operators can navigate into the rule editor with the request's path, headers, source IP, user, country or WAAP score values pre-filled as rule conditions. The operator narrows, generalises or adds to this starting point and saves the rule. This flow takes the question "how do I block or route this request?" out of manual analysis and into actionable rule design.
Live traffic subscriptions are not designed to remain open indefinitely. The maximum subscription duration is 30 minutes; subscriptions are automatically terminated when this limit is reached. Regular cleanup runs for disconnected clients to prevent zombie subscriptions from consuming resources. When the same client-pool combination resubscribes, the old subscription is closed and a new stream begins.
If the monitored pool is deleted or becomes unreachable, the system does not leave the live stream silently broken. An error event is sent to the client so that the screen can be cleaned up. This prevents stale or invalid data from appearing as live traffic in the operational view. Configuration changes propagate safely to the live monitoring session.
Subscription start and stop events for live traffic sessions can be logged. Who monitored which pool, when a subscription was started or stopped — this information is valuable for operational accountability. In security incidents, live monitoring access becomes part of the investigation trail. This visibility prevents the live tracking screen from becoming an uncontrolled observation tool.
Live traffic tracking is operated alongside timer safety, disconnection handling, bandwidth planning, configuration change propagation and audit behaviour.
Live data collection runs at the configured interval and the first data push is sent as soon as it is available. Long-running collection passes must not uncontrollably overlap with subsequent cycles. This model helps the management plane stay stable during active live monitoring sessions.
The current pool configuration is read on each monitoring interval. Pool changes can be reflected in the live tracking view so operators do not make decisions based on a stale topology. This matters especially during maintenance windows, failover events and sudden routing changes.
When a client connection drops, all associated live traffic subscriptions are cleaned up. This prevents orphaned monitoring jobs from accumulating on the server side. Events that occurred while the client was disconnected may be lost — since the replay buffer is client-side, this limit should be understood operationally.
The per-request payload size varies depending on the fields selected. A typical request context is around 2–5 KB; at 100 requests per second this generates roughly 500 KB/s of live data per operator. Field selection, filtering and interval tuning should therefore be planned together in high-throughput environments.
The system can log active subscription counts at regular intervals. This information is used to understand the monitoring load placed on the management plane. Operations teams can assess heavy live tracking usage in terms of capacity and access control.
In a high-availability cluster, the live traffic view is limited to the traffic seen by the node the client is connected to. This behaviour must be clearly understood — operators should be aware of which node they are observing through. Cluster-wide aggregate visibility is not presented as a current capability on this page.
Security teams can view a blocked request in the live table alongside its WAAP score and rule context. If the request is legitimate, the team moves from the same screen into creating an appropriate exception or narrowed allowlist rule.
SRE teams can spot a rising response time on a specific backend directly in the live table. Because path, pool, node and response time are visible together, the problem does not get lost in aggregate graphs.
Telecom and security operations teams can monitor abnormal request volume from a specific country or ASN in the live stream. Sample requests observed in the stream can immediately feed into source, path or pattern-based protection rules.
SaaS teams can watch whether a specific user or API key is generating unusual traffic in the live table. Because user context, path and response behaviour are visible together, rate-limiting or access rules can be written with greater precision.
Per-request visibility with 200+ FX variables, pause/replay and one-click rule generation. Let's walk through a live setup in your own environment.