Timing & replayable history
Every request is measured end-to-end and every attempt is recorded, grouped by server + path. Click an entry to load it back into the editor and send it again.
Two things are recorded for every single request, without you asking: how long it took, and that it happened.
Every request is timed
The dispatch — including auth, redirects and reading the response — is wrapped in a stopwatch, and the elapsed time is shown on the response next to the status code, colour-coded by latency. It’s also stored with the history entry, so the timing survives long after the response is gone.
This is the cheapest possible performance signal on an API you’re building. You don’t have to reach for a profiler to notice that an endpoint went from 40 ms to 900 ms after this morning’s change — the number is already on screen, and the previous attempts are right there in the sidebar to compare against.
The response header line also carries the status (colour-coded: 2xx green, 3xx cyan, 4xx amber, 5xx and transport errors red), the body size, and which executor ran it — on device or via the proxy.
History, grouped
Every attempt is appended to history and grouped by server + path. A group shows the path, the server it belongs to and a count; expanding it lists the individual attempts, each with its method, status, relative time (“4m ago”) and elapsed milliseconds.
Grouping by path rather than by time is what keeps a long session readable.
Fifteen attempts at /posts while you get a payload right collapse into one
row you can expand, instead of pushing everything else off the screen.
Because variables are stored as a template, grouping uses the
template path: /users/{userId} stays one group no matter how many
different ids you replayed it with.
Replaying
Click any attempt and it loads back into the editor — method, path, headers, body, and the variable values it was sent with. Change what you want and send. On phones, replaying automatically switches you to the Request tab.
That covers the most common thing anyone does with an HTTP client: the same request again, slightly different.
Persistence
History is written to storage and survives restarts, capped at the most recent 200 entries so it can’t grow without bound. Which storage it lands in — local device or a cloud endpoint — is your choice, and it can be switched at runtime. A trash icon in the history header clears it.