6.1 Time-Travel DOM Timelapse Inspector

How to inspect step-by-step DOM snapshots, synchronized network waterfalls, and console logs for any test run.

Reproducing a Failure Without Re-Running It

Re-running a suite to reproduce a failure you already saw is slow, and worse, it doesn’t always work – a step that failed because of a timing race, a slow backend response, or state left over from an earlier step in the same run can pass cleanly on retry, leaving nothing to look at. The Time-Travel Inspector sidesteps that problem entirely: every step in every run already captures the evidence it needs at the moment it executes, so debugging means scrubbing back through what actually happened, not hoping the problem happens again on demand.

What Gets Captured Per Step

Click into any run from Run Reports to open the inspector, then drag the scrubber across the timeline – each position corresponds to one executed step, and three things are captured for it: a DOM snapshot taken immediately before the action ran and another immediately after, so diffing the two shows exactly what the step changed on the page; every network request that fired inside that step’s window, laid out as a waterfall with method, status code, timing, and payload, so a slow or failed call stands out visually against the ones around it; and the console log entries emitted in that same window, including any error or warning the browser itself raised.

Reading a Failure Backwards

The most useful move is usually to scrub to the step just before the one that failed, not the failing step itself – the before/after DOM diff on that prior step often shows whether the page actually reached the state the next step was expecting. If the snapshot shows the element the failing step needed was never rendered at all, that points at a timing issue rather than a broken selector; if it was rendered but under different markup, that’s the selector-drift case CertiHeal is built to catch automatically on the next run.

When the Waterfall Tells the Real Story

• A step that times out waiting for an element is sometimes actually waiting on a slow API call – check whether a request in that step’s window is still pending or returned late before assuming the selector itself is at fault.
• A 4xx/5xx response sitting in the waterfall right before a failure is worth checking even when the step itself looks unrelated to that call – a background request failing silently can leave the page in a state the next step never anticipated.

• CertiHeal Self-Healing — What happens automatically when a step’s DOM diff shows a locator that stopped resolving.
• UI Selector Drift & Iframe Timing — A ranked diagnostic path for turning a Time-Travel Inspector finding into an actual fix.