Debugging guides
LogRocket local debugging: from a recorded session to a repeatable case
In the recording, a customer opens the navigation menu, changes workspaces and taps the close button. The menu stays open and covers the page. On the developer’s laptop, the same button works.
The recording shows the order of actions. To test a patch, repeat that order in a browser running the changed application.
There is another complication for localhost and VPN-only apps: the recording itself may be missing resources. Before investigating this hypothetical menu bug, establish whether the broken view is the application or the playback.
Localhost support is not the missing feature
LogRocket documents support for localhost and private development servers. There are conditions around access to the resources used by replay, rather than a blanket prohibition on local applications. 1
LogRocket retains resources for playback when it can retrieve them. Its local-development guide describes a fallback to live resources when the servers cannot reach assets on localhost or a private host. That fallback depends on the viewer’s access to those resources; the guide also calls out HTTPS requirements. 1
A missing stylesheet in playback may be a retrieval problem, not the state of the application during the incident.
Do not weaken browser security or expose an internal server merely to make a demonstration load. Use an approved environment or resolve the recording’s asset requirements with the team responsible for that setup.
Check the playback assets before fixing the menu
For the menu example, inspect the visible sequence, viewport information and available console or request context. LogRocket’s error-reporting workflow combines user activity with network and console logs; those details can narrow the investigation beyond the video-like view. 2
Check the stylesheet and image requests needed by the replay, then compare playback from a browser with the approved network access. A failure limited to viewers outside the VPN suggests a different investigation from a close button that also fails in the application.
If missing CSS explains the apparent overlay, resolve the replay’s resource access first. The menu-close bug still needs confirmation in the running application.
Write down the transition that matters
A useful reproduction note is more specific than ‘the mobile menu will not close’. For this hypothetical case:
Start: narrow viewport, workspace A selected.
Action 1: open navigation.
Action 2: switch to workspace B without leaving navigation.
Action 3: press the menu close button.
Observed: workspace content changes, but the menu remains open.
Expected: close the menu and return focus to its trigger.Now try to reproduce that sequence on the relevant application version. Opening the menu after the workspace switch is a different sequence. A wider viewport can also select a different navigation implementation.
Add any unknown preconditions to those notes. The sequence is a recipe to test, not evidence that the local failure has already been reproduced.
Preserve the failure once it exists locally
If the transition is supported by StatePort, capture it in the managed browser, review the result and save a State Card. Test its recorded journey, rather than relying only on the final screen: the action that leaves the menu open is central to this case. 3
Start the changed frontend and select Local app on the Card. StatePort can reuse retained matching dependencies while executing the current local application. It validates the selected setup and reports missing or incompatible material instead of silently broadening access. 4
Check the viewport and the workspace-switch transition in the actual reopen. If either differs in a way that hides the failure, keep the Card marked incomplete for this purpose and use a focused test or another setup.
The StatePort capture is separate from LogRocket. There is no automatic conversion of the recording URL into a Card in this workflow, and no promise to recover a customer’s server state that was never retained.
What should change after the patch?
Check more than the overlay disappearing. In the proposed expectation, focus returns to the menu trigger. The workspace should remain B, and the next menu open should work normally. These are example criteria to adapt with the person reporting the issue.
Compare those observations before and after the patch on the same intended setup. If the candidate loads a different workspace or uses a different navigation layout, record the difference instead of claiming a like-for-like check.
A local fix for this transition says nothing by itself about unrelated dead clicks elsewhere in production. Keep the original LogRocket incident and the local verification linked in the team’s issue tracker so the scope stays clear.
Three different outcomes of this investigation
If the recording makes the cause obvious and an existing test exercises the transition, use that test. If the issue is simply missing resources in playback, fix the playback setup. Neither case requires a State Card.
A third outcome is a real menu bug whose workspace-switch setup is costly to repeat. That is the case for trying StatePort; LogRocket can remain the source of production observations.
Check StatePort’s current scope before capturing a real internal application. Use approved test data, and review the saved material before sharing it. The Sentry local-reproduction guide covers the related case where the starting evidence is an exception rather than a visible interaction.
Sources
Written by StatePort. Documentation checked on 13 October 2026. The navigation scenario is invented; this is not a customer case study or a LogRocket import guide.