A pair is a hypothesis you review.

How suggestions are made

TracePair proposes exact class, method and selector-or-navigation-URL matches that appear once in each capture and move forward in both sequences. It does not use call IDs as cross-capture identities. Repeated signatures are left for manual alignment, and reordered candidates can remain unpaired. Suggestions are clearly provisional until you confirm them.

Open Edit pairs to remove a suggested pair or add a reviewed pair. The selectors show physical source lines and monotonic times. Helper actions are hidden from the default selector to reduce noise; Show helper actions as well makes every recorded action available. Script-evaluation actions can be selected, but their expressions are discarded rather than executed or exported.

An anchor cannot be used twice, cross another anchor, or share its start time with the next anchor. Those cases need a different alignment. A repeated click may be a retry, a second user task, or an unrelated event; match its surrounding context before joining it to the other capture.

The boundary is the next paired action

Each interval begins at its paired action’s start, inclusive. It ends at the next paired action’s start in that capture, exclusive. An unpaired action between those anchors does not cut the window. When you add or remove a pair, every request is regrouped from its native start clock.

A: click ─── helper ─── wait
B: click ─── extra action ─── wait
   ↑ paired anchor           ↑ next paired anchor

The last interval includes all remaining recorded requests. We do not infer a recording end from the last completed action. Requests before the first anchor remain unassigned. Missing or foreign page references also remain unassigned, even if their timestamps happen to fit. The count of assigned and unassigned requests always accounts for the full imported network stream.

Read outcomes and order separately

The sequence comparison includes endpoint identity, method, HTTP status, aborted state and whether a failure was recorded. It preserves repeated occurrences and cross-endpoint ordering. The endpoint summary is a second view, not a replacement for the ordered list: A → B and B → A can have identical per-endpoint counts and still differ.

Equal-time rows have uncertain strict order. If either interval has tied clocks, the interface marks the order review. Source lines break ties for stable display. Differences in relative timing are visible as context; no latency-regression threshold, statistical significance or cause is inferred.

“End recorded” describes the action record. “Error” means the after record contains an error. “Incomplete” means the after record is absent. None of these is an application health score. In particular, an incomplete action is never silently promoted to success.

Choose endpoint equality deliberately

Begin with exact matching. Query values are hidden in the display label, while endpoint aliases remain distinct when the raw URLs differ. Open source evidence to inspect the full URL locally. Use a broader mode only when you can justify the equivalence from your application.

What leaves the browser

The comparison does not send input files to a server. A downloaded review contains the intervals you selected plus all unassigned requests and summary counts. By default, it uses generic source names and endpoint aliases. Raw URLs, selectors, call IDs and filenames require an explicit export checkbox and appear in the preview. Methods, statuses, timings and counts are still data; the default export is not an anonymity guarantee.

Two green responses can hide the wrong comparison.

Consider this original hypothetical pair of test runs. Both contain a click named “Continue” and a later GET /status returning 200. In run A, Continue submits an order review. In run B, Continue dismisses a newsletter dialog before the order form appears. Joining those clicks because their labels match creates a plausible-looking comparison of different visitor tasks.

Start with the state before the action.

Read the available DOM snapshots, action logs and source context in the official Playwright Trace Viewer. Establish what the visitor could see, which control received the action and what stage of the application it represented. TracePair’s suggested anchor is a candidate alignment; it does not inspect the semantic meaning of every screen.

If the order-review action occurs later in run B, pair that action with run A’s order review. Keep the dialog dismissal as an unpaired action and examine which interval now contains its requests. If the corresponding action was never captured, leave the anchor unmatched rather than inventing a completed step.

Then challenge endpoint equality.

Run A: https://shop.example/status?order=demo-a   → 200
Run B: https://shop.example/status?order=demo-b   → 200

Path-only key for both: /status
Exact URL keys: two different resources

Path-only comparison can legitimately group repeated tests that intentionally use different synthetic IDs. It can also conceal the fact that one run inspected the wrong order. Write down why those IDs are equivalent for this test before broadening the mode. A matching HTTP status does not prove matching response bodies, business state or authorization.

Keep retries as an ordered story.

Another pair may show A: 503 → 200 and B: 200 at the same endpoint. The final successful response agrees; the request sequence does not. That difference is worth investigating, but it is not automatically a user-visible failure. Compare the action’s recorded end, application state and retry policy before deciding whether the change is expected.

Similarly, two successful requests in the reverse order can matter if one depends on the other. Endpoint totals alone cannot answer that question. Equal native timestamps also do not establish which event happened first; keep the order uncertainty instead of treating display order as a measured sequence.

A review statement another person can reproduce.

Write: “I paired these two order-review actions because the prior application states match; I kept exact URL matching because the order IDs should be identical; run A contains a failed request followed by a retry; the UI outcome remains unverified.” Name the source lines for each observation. This is stronger evidence than “A has more red rows,” and it preserves the unanswered question for the next investigation.