A tunnel that only forwards traffic tells you nothing when something breaks. The Traffic Monitor records every request that arrives through yours, so you can answer "what did they actually send me?" without adding logging to your app.
Reading the stream
Each row is one request: method, path, status code and duration. Click any row to see the full picture — request headers, request body, response headers, response body.
That detail matters most when the caller is not you. A payment provider or a partner's integration will send headers and casing you did not anticipate, and the monitor shows the bytes as they arrived rather than as your framework re-serialised them.
Filter down to what broke
With a busy dev server the stream moves fast. Three filters do most of the work:
- By method — isolate the
POSTthat matters from a flood ofGETpolling. - By status — filter to
4xxand5xxto see only failures. - By path or keyword — narrow to one endpoint.
Combining status and path is the fastest route to a specific bug: filter to 5xx on
/webhooks/stripe and you are looking at exactly the deliveries your handler rejected.
Promote a request into a collection
When you find an interesting request, save it into a collection. It becomes a normal saved request you can edit and re-send from the REST client — which means real traffic from a third party turns into a repeatable test case without you hand-copying a payload.
This pairs well with testing webhooks locally: capture a real delivery once, promote it, and replay it forever.
What to watch for
- Duplicate deliveries — most providers retry, so seeing the same event twice is normal and your handler must tolerate it.
- Slow responses — the duration column is measured at the tunnel, so it includes your handler's real processing time.
- Unexpected methods — a
HEADorOPTIONSyou did not plan for often explains a mysterious405in someone else's integration.