How to read Simquence output

Simquence does not tell you what is slow.
It tells you why the user waited.

The app's own information panel, shortened. The full version ships in the app, under the book button.

The screen, element by element

• The histogram (makespan distribution). Runs counted by how long the whole flow took. A tight cluster is predictable; a long right tail means some runs go badly; two humps mean two behavioural modes, worth explaining before you optimise anything.
• The percentiles (p50 / p90 / p95 / p99). p50 is the typical experience; p99 is what 1 in 100 users hits. They describe exposure, not targets; lowering one blind usually shifts the cost elsewhere.
• The critical path. The chain of tasks, queue waits and delays that set a run's finish time: literally why the user waited. Critical does not mean slow; a slow task off the path delayed nobody.
• The critical-path frequency chart. How often each chain was the bottleneck. A path dominating more than about a fifth of runs is how your design behaves rather than a fluke. This chart is the real answer; the histogram is context for it.

A worked example: the shipped Checkout model

Load Examples → Checkout and press Run. The model: a click fires user.checkout_clicked, a UI task handles it and emits checkout.started, which fans out to four backend tasks, three of them at once. Two of those (db.load_cart and db.load_saved_cards) share a database context with concurrency 1, so one always queues behind the other. A fixed 150 ms delay sits on the wiring to net.fetch_promotions: a debounce, added for politeness.

Intuition says the slowest backend, the shipping quote around 165 ms, dominates. The frequency chart says the chain through the 150 ms debounce is the critical path in most runs. A politeness feature owns the median; no profiler could have told you that before the system existed.

How to use it

• One run is not evidence. Contention and coordination delays are not noise to average away; they are the system.
• Name the dominant behaviour before proposing any fix. A task that never appears on a dominant path changes nothing when you speed it up.
• The long tail can usually be left alone unless you design to a strict worst case. Optimising rare worst cases is how systems get complicated without getting faster.
• A representative run (commonly the median or p95 of a dominant mode) illustrates; it does not explain every outcome.

Simquence does not optimise systems.
It exposes structure.