Request X-Ray
One request, seven layers, and seven switches that decide what happens to it. Break the pipeline on purpose and watch the same request take a different route, spend a different amount of time, and reach a different outcome.
Nothing here calls a real service. The whole simulation runs in this tab, and the URL carries the exact configuration, so any run on this page can be sent to somebody else and reproduced precisely.
Scenarios
Each scenario sets all seven switches at once. Change any switch afterwards to take it somewhere new.
Pipeline switches
Grouped by the layer that owns the behaviour. Browser and database have no switches; they do what they are told.
Adds a repeatable amount of extra latency to every layer, seeded from the configuration.
Refuses the request at the router with 429 before any downstream work happens.
The deadline applies to each attempt separately. Retries wait 30ms, then 60ms, then 120ms.
The handler raises 503 before it reads anything, so the failure is immediate and total.
A miss falls through to the database. A stale entry answers just as fast as a fresh one, which is the problem.
Trace
- Status
- idle
- Total latency
- 0ms
- Downstream calls
- 0
- Attempts
- 0
- Terminated at
- –
- Pattern
- –
Layer detail browser
Configured behaviour
Last run outcome
Hop table
The same trace without the animation. This is the accessible equivalent of the diagram and the fastest way to read a run.
| # | Layer | Attempt | Outcome | Latency | Note |
|---|
Compare
Pin the current configuration, change the switches, and read the two runs side by side.
Nothing pinned yet.