Why is Test Replay unavailable for a Cypress run recorded in Firefox?

## Why the browser decides this Test Replay is not a video and not a screenshot sequence. It is a recording of the run's **events** — commands, DOM mutations, CSS, network traffic, console logs, JavaScript errors — captured while the test executes and replayed in Cypress Cloud by regenerating the interface from that data. The capture is driven through the **Chrome DevTools Protocol**, the debugging interface exposed by Chromium-based browsers. That single implementation choice sets the support boundary. Chrome, Edge and the deprecated Electron browser expose the protocol, so they can be captured. Firefox and WebKit do not, so there is nothing for the recorder to attach to, and Cypress Cloud disables the Test Replay button for those runs with a message saying it is available on Chromium only. ## What you still get on an unsupported browser | Browser | Test Replay | Screenshots, videos, CI logs | Results and errors | | --- | --- | --- | --- | | Chrome / Edge / Electron | yes | yes | yes | | Firefox | no | yes | yes | | WebKit | no | yes | yes | Nothing else is lost. The run records, the failures carry their errors and stack traces per attempt, and the flaky flag still works because that is derived from attempt outcomes rather than from replay data. What disappears is the ability to step through the failing attempt afterwards. For a storefront monorepo that runs its checkout specs across a browser matrix, the practical consequence is that the Chromium leg is the one you can actually debug from CI. A sensible shape is to keep the deep, flake-prone journeys on a Chromium browser where replay is available, and treat the Firefox and WebKit legs as compatibility checks whose failures you reproduce locally when they appear. ## The other reasons the button is disabled Browser support is only one of four checks. When Test Replay is greyed out on a run you expected to have it, work through these in order: 1. **The recording Cypress version.** Test Replay exists for runs recorded with Cypress v13 and later; anything older has artifacts only. 2. **The browser.** It must be Chromium-based, per the table above. 3. **The project setting.** Test Replay capture can be switched off per project in Cypress Cloud settings, which stops the data being captured at all. 4. **The upload.** A spec whose replay failed to upload shows a disabled button with an error on hover; the exact message is in that spec's output. Network or proxy blocks and specs that outrun the project's run timeout are the usual causes. Note that *viewing* is a separate question from *capturing*. Test Replay renders in the browser you are sitting in front of, and very old Safari versions lack web APIs the viewer needs — which affects watching a replay, not recording one. Listing a run's failures through the Cypress Cloud CLI (`cy-cloud`) makes the gap concrete: each test comes back with the browser it ran in and, where one exists, a Test Replay URL. Filtering that output with `jq`, the command-line JSON processor, shows at a glance which of a matrix run's failures you can actually replay. ## Capture is a project decision, not a per-test one There is no way to ask for a replay of only the failing tests, or only the retried attempts, or only one spec. Test Replay capture is switched on or off for the **whole project** in Cypress Cloud settings, and when it is on it records every test in every recorded run on a supported browser. The same applies to the browser rule: you cannot opt one Firefox spec into replay, because the capture path does not exist there at all. That is why the browser matrix is where this decision actually gets made. If a storefront package's most flake-prone journeys only ever run on the Firefox leg, no setting will give you a replay of them; the fix is to make sure those journeys also run on a Chromium browser, where the evidence is collectible. ## What Test Replay never captures, on any browser Even on a fully supported Chromium run, some things are outside the capture: - `localStorage`, `sessionStorage` and cookies - Web sockets and server-sent events - Network traffic issued by `cy.request()`, which does not go through the application under test - Video and audio elements, and canvases inside a shadow root - Objects that are not declared as `type="image/svg+xml"`, and shadow DOM elements using manual slot assignment Knowing this list matters when you are chasing flake, because it tells you which hypotheses the replay cannot confirm or rule out. If the storefront's cart total depends on a value read from `localStorage` or delivered over a web socket, the replay will show you the DOM going wrong without showing you the input that caused it, and you need a different piece of evidence for that step.