Compare Screen Recordings for Bug Reports: Proving It Only Happens Sometimes

QA says the checkout button sometimes doesn’t respond. Engineering can’t reproduce it. Both sides have screen recordings — one where the flow works, one where it doesn’t — but “it just looks different somewhere in there” isn’t a bug report engineering can act on.

Why screen recordings are harder to compare than screenshots

A single screenshot comparison (like for UI regression testing) works because both images represent the exact same moment in a static layout. A screen recording adds a dimension screenshots don’t have: time. The two recordings may not be the same length, the cursor moves at slightly different speeds each take, and network/loading delays shift everything after them — so you can’t just compare frame 400 of one against frame 400 of the other and expect it to mean anything.

Align on events, not timestamps

Before comparing anything, find 2–3 shared visual anchor points in both recordings — a page finishing loading, a modal opening, a specific field being clicked. These are your alignment points; everything you compare should be measured relative to them, not to the recording’s raw timestamp.

Recording A: page load (0:02) → form filled (0:14) → button click (0:19) → success (0:20)
Recording B: page load (0:03) → form filled (0:16) → button click (0:21) → [nothing happens]

Once aligned this way, the divergence is obvious: both recordings match structurally right up until the button click, and then B simply stops producing the expected next event. That’s the moment worth investigating frame-by-frame — not the whole recording.

Isolate the divergence point

Trim both recordings to start at the last matching anchor point before the divergence (here: “button click”).
Extract frames from that point forward at a high rate — every frame if the window is a few seconds: bash ffmpeg -i recording_a.mp4 -ss 00:00:19 -t 3 -vf fps=10 a_frame_%03d.png ffmpeg -i recording_b.mp4 -ss 00:00:21 -t 3 -vf fps=10 b_frame_%03d.png
Compare the extracted frame sequences using DiffALL’s image comparison tool pairwise, or upload the trimmed clips directly to video comparison for a per-second similarity chart across just that window.

The per-second chart is the fast path here: instead of scrubbing manually, the similarity score drops sharply at the exact second things diverge — that’s your bug’s actual moment, timestamped precisely enough to hand to engineering.

What the divergence pattern tells you

What you see at the divergence point	Likely cause
A loading spinner appears in one and never resolves	A backend request is timing out or failing silently
The button visually depresses (click registered) but nothing else changes	Frontend event handler issue, not a backend problem
One recording shows a brief error toast, the other doesn’t	Intermittent server-side error — check logs for that exact timestamp
Layout looks identical but one is a few pixels shifted	A race condition in a CSS animation or lazy-loaded element
The click lands on a slightly different pixel in each	The “bug” may be a mis-click, not a real defect — check click coordinates

That last row matters more than it sounds: comparing recordings sometimes reveals the “bug” is actually two testers clicking a very-slightly-different spot on a button whose hit area shrank after a padding change — a real bug, just not the one anyone assumed from the description.

Making flaky bugs reproducible from recordings

If the divergence correlates with something environmental rather than a fixed code path:

Record network conditions alongside the screen (DevTools’ Network tab export, or a packet capture) so a slow-request theory can be confirmed or ruled out from the same time window.
Capture multiple takes of the same flow and compare all of them against each other, not just one working vs. one broken — a bug that reproduces in 1 out of 5 attempts needs more than a single pair to characterize.
Note exact wall-clock time for each recording — if failures cluster around specific times, that points to a backend load or cron-job interaction rather than a pure frontend bug.

Checklist

[ ] Find 2–3 shared visual anchor points and align both recordings on events, not raw timestamps.
[ ] Trim both clips to just before the divergence — don’t compare the full recordings frame-by-frame.
[ ] Use a per-second similarity chart to pinpoint the exact moment of divergence.
[ ] Check click coordinates before assuming a backend cause — sometimes the “bug” is a mis-click.
[ ] Capture multiple takes for intermittent bugs rather than relying on a single pair.

“It only happens sometimes” becomes a fixable bug report the moment you can point to the exact second two recordings stop matching. Compare the two recordings instead of describing them in words.