A game of network pong
HTTP requests leave their host as small, uniform circles. At the RCWeb paddle they become response balls and return to the same host: the status code appears only on the return journey, and larger responses produce larger balls. Size uses a logarithmic scale of response bytes. All statuses bounce. Colour on arrival identifies the host; return colour identifies the status.
WebSocket diamonds follow the recorded direction: IN → to RCWeb, ← OUT to the client. Frames have no HTTP status or implied acknowledgement.
Response shapes: filled circles for 1xx, 2xx and other 3xx; hollow circles for 304 Not Modified; triangles for 4xx; squares for 5xx. A yellow lightning bolt appears below responses whose X-WTM-Cache-Hit header is true.
Destinations use the RCWeb app catalogue, including controllers. Room and client IDs are read from the URL when available. Tap a moving event to inspect it. On phones, hosts use short H1, H2 labels: tap a host label to see its full address. Tap the gear for filters, speed and labels.
One HTTP circle represents one request throughout its round trip; the bounce does not create another ball. Each WebSocket diamond represents one logged frame. At normal speed, HTTP balls remain visible for about three seconds, so the in-flight count can exceed events per second.
HTTP logs arrive after completion. Flight time is visual pacing, not request latency. Counters cover all received traffic, even when filtered; events/s includes both HTTP requests and WS frames. Monitor traffic is excluded.
Hidden Secure info groups events whose entire URL was removed for security. URLs with masked room or client values still group under their visible app or path.
Auto keeps a stable sample of labels throughout each flight, reducing clutter during bursts. Rendering follows the display refresh rate. Queues and particles are bounded; omitted visuals are counted. Feeds reconnect automatically; disconnected periods cannot be replayed.