See what your
tunnels are doing

Traffic metrics arrived one feature at a time, and each one brought its own chart. Tunnels counted requests. Webhooks counted deliveries. The agent summed something in between. Firepuncher counted forwards. Four components, four bucket sizes, four opinions about what the y-axis meant.

The result was that you couldn't compare anything to anything. A spike on one chart and a flat line on another might be the same event seen twice, or two unrelated things — and the only way to know was to remember how each one was built.

So we deleted all four and wrote one.

Every connection now reports the same shape: traffic over time, plus three numbers above it. Open a tunnel, an agent, a webhook receiver or a firepuncher forward and the widget is identical. 24 hours, 7 days, 30 days.

What the three numbers are still differs, because the honest answer differs:

Two of those are deliberate refusals rather than oversights.

The account view has no latency. Latency belongs to a connection. Average it across every tunnel on an account and you get a number that describes nothing — one that moves when a chatty tunnel gets busy and stays put when the slow one gets slower.

Firepuncher counts forwards, not requests. A forward is a TCP session, so the useful second dimension is how long it lasted, not how fast it replied. An SSH session open for an hour is one forward; calling it one request with 3,600 seconds of latency would be arithmetic, not information.

A webhook receiver's chart splits deliveries four ways: delivered, failed, rate limited, rejected. That single split answers the only question anyone asks when a webhook stops working — whether the provider stopped sending, or you turned it away.

Outcomes are recorded hourly, which has one honest consequence worth knowing: on the 30-day view they're absent rather than approximated. The coarser table behind long ranges doesn't record them, and an invented breakdown would be worse than none. An empty outcome section at 30 days doesn't mean nothing failed — it means look at 7 days.

Per-tunnel hourly rows are purged after two weeks, so anything longer than 7 days comes from rollups. The account's own hourly table is never purged, which is why the account chart stays hour-resolution even at 30 days — it's the one place where the long view is the same shape as the short one rather than a coarser cousin.

It calls the same endpoint you can, with an API key:

kind is account, tunnel, agent or firepuncher; the response is one shape for all of them. The metrics array arrives already labelled, so a status board can render whatever it's given rather than hard-coding names that may gain a fourth entry later. A null value means “no data in this range”, which is not the same as zero and shouldn't be drawn as a floor.

Nothing on these charts includes a request body, a header, or a URL. That's not an omission to be fixed later — it's what makes them safe to keep, aggregate and retain.

When a specific tunnel misbehaves in a way counters can't explain, there's a separate per-tunnel capture mode that records full requests and responses for a bounded window. It's administrator-initiated and off by default, because turning on payload capture is a privacy decision and not something a chart should be able to do quietly.

The chart tells you how much. The connection log tells you who — every request that met a tunnel's access rules and every one that didn't, with the client address and the rule that decided. Capture tells you exactly what, and only when someone deliberately asked.