This is a recommended blueprint for investigating a slow or unresponsive interaction with Recorder. Adapt it to the delay you can observe: a request that takes a long time, a spinner that remains after a response, or a click with no visible result. The aim is to preserve the initiating action and enough timing, screen, and error evidence to guide the next investigation.

Use it with bug reproduction or test execution when the check is already defined.

Choose the mode and follow this 10-step path

• Select Explore for an open-ended delay investigation or new performance report.
• Select Test case when a case states the response or completion criterion; enter its case ID and later choose Passed, Failed, or Blocked.
• Select Verify fix for a known performance issue on a candidate build; choose the issue and later choose Fixed or Not fixed.

1. Record the build, data size, cache/login state, device/network conditions, expected behavior, and measurement method in Description.
2. Select Start recording and perform the affected action once.
3. Capture the waiting state and, when it arrives, the completed state.
4. Select Stop → Investigate before the initiating action leaves the retained timeline.
5. Confirm the initiating action and input.
6. Locate the relevant request or local/page work and inspect its start, end, duration, response, and dependencies.
7. Compare completion time with the screenshot or manually measured visible result.
8. Add comments that identify every measurement’s source and avoid causal overstatement.
9. Choose the supported mode result, or leave it unselected when evidence is blocked/inconclusive and the mode has no matching result.
10. Finish Description, review/download/send, verify the handoff, then use New recording.

Measurement	What it means	What it does not prove
Request Timing	Captured interval/phases for one request	Total user-visible wait or responsible backend function
Manual wait	Time measured with the method you state	Which request or page task caused it
Environment connection	Browser-reported connection estimate	Throughput of the recorded request
Timeline long task	Recorded main-thread interval near the symptom	Causality without further comparison
Screenshot	Visible state at its timestamp	Exact duration by itself

Prepare a comparable attempt

Open the application and Recorder’s side panel. Select local recording or the connected project, and prepare the affected data. Note the application build, dataset size, cache/login state, and any network/device conditions you deliberately changed. Recorder’s Environment tab supplies some browser and page context, not these application-specific preconditions.

Use a title such as Search delay - A1 - warm cache. A found issue can prefill an unchanged Title and offer its description; add it only when it helps this attempt. Changing one condition for A2 should produce a separate result you can compare.

Capture the start of the delay

1. Select Start recording and wait for the active state.
2. Perform the affected action once. Repeated clicks can create extra requests or change the problem; include them only if that is the behavior you need to reproduce.
3. Use Capture for the visible viewport while the spinner, unchanged screen, or error is present. Use Area when a region is enough, keeping the submitted value and result area in view.
4. If the result arrives within the useful capture period, take another image of the completed state. Note how you measured the user-visible wait, if you measured it separately.
5. Select Stop, then Investigate before the initiating action leaves the retained timeline.

For a longer unresolved wait, stop with the beginning and waiting state preserved rather than silently losing the initiating action. Write Still waiting at Stop and the observed duration. Stopping freezes the recording; a response arriving later will not update that stopped evidence. A later screenshot or another recording can show a later state, but identify it as later evidence and state the gap.

Locate the delay in the sequence

Separate three moments: the action begins, the relevant request completes, and the expected state becomes visible. Recorder can provide request timings and captured states; screenshots alone do not measure the exact duration of the user’s wait.

Establish the input and request interval

1. In Actions → Recorded Actions, select the initiating search, save, or navigation. Inspect Target, available Captured value, What changed, and Element & form state. Confirm the intended action/input occurred and whether the page was already busy, disabled, or showing invalid fields.
2. Expand the action’s request count and select the operation’s request. In Payload, confirm the actual query/record so you do not time unrelated background traffic. Use Open in Network tab to inspect retries or dependent requests. Open Network directly if nothing is associated.
3. Open Timing. Pin the useful start, end, duration, or phase by right-clicking the field → Pin. Keep the units and source. A missing phase is unknown, not zero; linked Browser performance timing is a separate measurement source from the request timing.
4. Open Response. Was the required result returned, an application error reported, or the body unavailable? Check the failure summary and Headers when cancellation, blocking, redirects or a recorded cache source could explain the wait. A 200 header does not guarantee that the response body completed successfully.
5. Open Timeline and inspect the waiting/completion image relative to these events. A request row is at its start time: use the Timing end before saying the spinner outlasted it. Select the screenshot to inspect the actual state at that time.

For example, a waiting-state screenshot captured after the relevant response ended supports “the wait continued after this request.” It does not prove the request was the final dependency, nor that the page was frozen throughout the interval.

Follow the branch supported by the evidence

Observation	Where to look next and why	Useful finding to save
No matching request is captured	Check broader Network, action/form state, page reaction and relevant Console details. The operation may be local, blocked before sending, or outside capture scope.	What input/state was captured and whether a relevant request could be found; leave the missing link explicit
A relevant request is long or unfinished at Stop	Inspect Timing, status/failure summary and available response. Check whether the image falls within that interval.	Recorded duration or unfinished state, plus the visible wait; a wait phase does not identify a backend handler
Several requests retry or wait on one another	Read the Session network waterfall, then inspect each request’s input, result and end time.	The sequence that prolongs the operation; do not add overlapping durations as if they were sequential
The required response completes but the spinner remains	Look for later requests/stream updates, relevant exceptions and page reaction; inspect nearby Timeline long tasks.	Correct/incorrect response plus the later visible wait and any supporting diagnostic event
The page changes but the user cannot interact normally	Inspect Timeline long-task duration/attribution and Console stack context.	An interval worth profiling; proximity does not prove the task caused the symptom
The display depends on a live update	Open captured EventStream or WebSocket messages and compare their time/data with the display.	Whether the relevant update was observed; preserve safe WebSocket excerpts manually because local downloads omit frames

Click a relevant Console entry to inspect Message, Stack trace, source and arguments. Pin the exact useful detail, not every error. Use Initiator on a request for available script-origin context a developer can follow. Cause returns to a likely associated action, which still needs checking against your input and timeline.

Separate interaction timing from starting conditions

Open Environment to compare browser, viewport/zoom and connection context across attempts. Its Document load describes the document open when capture started and may predate the interaction. Its connection tier is a browser estimate, not a measurement of this request’s throughput.

In Timeline, open available long-task, paint or resource events for their recorded detail. Some buffered measurements can predate Start. Standalone performance/lifecycle entries do not have their own note editor; copy a useful event’s time, duration and source into the initiating action’s note or Description. A linked resource measurement may instead be available and annotatable under request Timing.

Save the timing argument

Open Notes, select each useful pin and View evidence. Use Add comment to connect measurement and observation: This request ended at [time], but image [reference] at [later time] still shows the spinner. Check later dependencies and page work; the recording does not identify the responsible function. Mark the deciding evidence Important, then Save comment.

Add a separate note to each waiting/completion image in Screenshots & Attachments. Label a still-waiting-at-Stop result explicitly. If the recording cannot locate the delay, preserve that gap and choose one next capture or profiling question. If you already have a clear interval and relevant evidence, hand it off before expanding into unrelated performance measurements.

Save the conditions with the observation

Open Notes, remove irrelevant pins, and use Add comment on the useful ones. View evidence should lead to the exact timing field, log entry, or image. Keep the measurement source in the text so a recipient can distinguish a request duration from a manually measured UI wait.

In Description → Split, adapt this record:

Interaction / attempt: search / A1
Build / environment / role: [fill in]
Input / dataset / cache state: [fill in]
Expected: [expected response or agreed timing criterion]
Observed: [result appeared, error, or still waiting at Stop]
User-visible wait: [duration and measurement method, or not measured]
Relevant request: [method/path and recorded duration, or unavailable]
Evidence: [NOTES]
Capture gap: [late response, missing body, or other limit]
Comparison: [other attempt reference and changed condition, if any]

Select [NOTES] and choose Add → Notes to insert saved comments/pins. Read Preview and resolve any save error. Use Undo for an insertion in the wrong place. If you revise a source note, update its inserted copy too. Label estimates as estimates instead of giving them the appearance of measured timings.

Preserve comparisons and hand off

Review Privacy preview, authored text, console details, and image pixels. Select Download report and check completion in Chrome. Open session.md, available notes.md, network.har, and the relevant PNGs. Copy important viewer-only measurements into Description because the folder does not recreate every diagnostic panel.

Attach reviewed evidence through the bug-report workflow and check the recipient can open it. Before New recording, add the folder reference to your comparison notes. Use A2 for a changed cache state, dataset, or build, keeping all other known conditions the same where practical. Describe the difference in its title/notes rather than merging the attempts into one unexplained average.

Use a browser profiler for detailed main-thread analysis or repeatable benchmarks. Recorder’s performance evidence is partial: it does not calculate INP or CLS or provide throttling presets. The shared workflow guide covers partial downloads and other handoff recovery.