skip to content

Saved Failure Media

3 roadmaps6 questions

The files a run leaves on disk - a screenshot taken by hand or automatically on failure, and a video of the spec. Interviewers ask because in CI that is often all you get to read.

on this pageshow

explore

questions

6

In Cypress, what does a failing `cypress run` leave on disk by default?

level: juniorimportance: must knowfreq 82%

answer

  1. Two folders, only one filled by default
  2. Failure evidence automatic, film opt-in
  3. screenshotOnRunFailure is true by default
  4. video is false by default
  5. Folders are emptied before each run

basics

~20 s

One PNG per failed test, written under cypress/screenshots, because screenshotOnRunFailure defaults to true. No video: the video option defaults to false, so cypress/videos stays empty until you enable it. Neither of those happens in cypress open mode.

solid answer

~40 s

By default `cypress run` leaves screenshots and nothing else. `screenshotOnRunFailure` is `true`, so every failed test produces one PNG under `screenshotsFolder`, which defaults to `cypress/screenshots`; the file sits in a folder named after the spec and its name ends with ` (failed)`. Video is opt-in: `video` defaults to `false`, so `cypress/videos` stays empty until you turn it on, and when you do, Cypress records one video per spec file rather than per test. `cypress open` does neither, though a hand-written `cy.screenshot()` writes a file in both modes. One more default bites in CI: `trashAssetsBeforeRuns` is `true`, so Cypress empties the downloads, screenshots and videos folders before each `cypress run` — the job has to archive them itself.

go deeper

for a junior

Know the two defaults by name: screenshotOnRunFailure is on, video is off. Be able to say which folders the files land in without looking them up.

for a middle

Be ready to explain why the folders are empty at the start of a run, and what one video per spec file means when a spec holds forty tests.

for a senior

Show how the artefacts leave the runner: an archive step that runs on failure, and the checks you make when a failed spec left no image at all.

for a principal

Own the policy around the files: which pipelines record video, how long artefacts are retained, and who is allowed to open them.

## The two automatic outputs, and the one that is off `cypress run` is the mode that leaves files behind, and out of the box it leaves exactly one kind of file. - **A screenshot of every failed test.** The `screenshotOnRunFailure` configuration option defaults to `true`. When a test ends with an error, Cypress captures the browser and writes a PNG under `screenshotsFolder`, which defaults to `cypress/screenshots`. - **No video.** The `video` option defaults to `false`. `videosFolder` (`cypress/videos`) is where a recording would go, but nothing is recorded until you set `video: true` — and then Cypress records **one video per spec file**, not one per test. - **Nothing automatic in `cypress open`.** Interactive mode takes no failure screenshot and records no video. It does not need to: the Command Log is still on screen and the spec can be re-run. The exception to all of it is a capture you asked for. `cy.screenshot()`, and the chained `.screenshot()` on an element, write a PNG in **both** modes into the same `screenshotsFolder`. ## Where each file lands | Option | Default | What it decides | |---|---|---| | `screenshotOnRunFailure` | `true` | Whether a failed test in `cypress run` produces a PNG | | `screenshotsFolder` | `cypress/screenshots` | Where manual and failure screenshots are written | | `video` | `false` | Whether `cypress run` records a video per spec | | `videosFolder` | `cypress/videos` | Where those recordings are written | | `trashAssetsBeforeRuns` | `true` | Whether the asset folders are emptied before a run | ## How the automatic screenshot is named The path is `{screenshotsFolder}/{adjustedSpecPath}/{testName} (failed).png`, built in four steps: 1. The spec's own path becomes a folder, with the segments that every spec shares stripped out — for `cypress/e2e/tickets/queue.cy.js` in a project whose specs all live under `cypress/e2e/tickets/`, that folder is just `queue.cy.js`. 2. The test name is the suite titles and the test title joined with ` -- `. 3. ` (failed)` is appended, which is how you tell an automatic capture from one the spec asked for by name. 4. If that exact filename already exists, the next one gains ` (1)`, then ` (2)`, unless the capture was taken with `overwrite: true`. So a failing `it('filters by status')` inside `describe('ticket queue')` leaves `cypress/screenshots/queue.cy.js/ticket queue -- filters by status (failed).png`. ## The folders are emptied before the run, not after `trashAssetsBeforeRuns` defaults to `true`, and it does more than delete stale images. Before `cypress run` starts, Cypress removes the **entire contents** of `downloadsFolder`, `screenshotsFolder` and `videosFolder` — every file and every nested subfolder, not only media. The folders themselves survive. This never happens in `cypress open`. Two consequences are worth saying out loud in an interview: - On a persistent CI runner or a developer machine, what you are looking at is always the **last** run's evidence. The previous run's images are gone unless the job uploaded them. - Anything else parked in those folders is deleted too. A support-ticket suite that writes a CSV of seeded ticket ids into `cypress/screenshots` will find it missing at the start of the next run. ## Getting the files off the machine Cypress writes into the project folder on the machine that ran the tests, and uploads nothing on its own. That puts three things on the pipeline rather than on Cypress: - The artefact step has to run **even when the test step failed**. A job that archives only on success is the usual reason a team believes Cypress "did not take a screenshot" for an intermittently failing ticket-queue spec. - The archive has to happen at the end of that job, because the next run trashes the folders. - If you want the video of that flaky spec, someone has to have set `video: true` before the run — you cannot ask for it after the fact. ## The quick sanity checks when nothing is there - Was it `cypress run`? Open mode writes no failure media at all. - Is `screenshotOnRunFailure` still `true`? It can also be overridden for a single suite or test through test configuration. - Did the test actually fail, or was it skipped? A pending test produces no failure screenshot. - Is the CI job archiving `cypress/screenshots` and `cypress/videos`, or a path someone renamed with `screenshotsFolder`?

  • What exactly is the automatic failure screenshot called?
    It is `{screenshotsFolder}/{spec path}/{suite titles -- test title} (failed).png`. The spec folder drops the path segments every spec shares, the suite and test titles are joined with ` -- `, and the ` (failed)` suffix marks it as the automatic capture rather than one your spec requested by name.
  • Does `cy.screenshot()` still write a file in `cypress open`?
    Yes. Manual captures are written in both modes, into the same `screenshotsFolder`. Only the automatic capture on failure and the spec video are limited to `cypress run`. In open mode the asset folders are never trashed beforehand either, so files from earlier sessions stay where they are.

saying these in an interview costs you the question

  • Says Cypress records a video of every run by default
  • Expects failure screenshots from cypress open
  • Thinks one video is produced per test, not per spec
  • Assumes artefacts accumulate across runs on a runner
  • Believes screenshots require recording to Cypress Cloud
open as a page

In Cypress's `cy.screenshot()`, what do capture 'viewport', 'fullPage' and 'runner' capture?

level: middleimportance: must knowfreq 60%

basics

~20 s

viewport captures the application as it fits the current viewport, fullPage scrolls and stitches the whole application top to bottom, and runner captures the entire browser viewport including the Cypress Command Log. The default is fullPage.

open as a page

A Cypress failure screenshot shows the ticket queue looking healthy. Why?

level: seniorimportance: should knowfreq 44%

basics

~20 s

Taking a Cypress screenshot is asynchronous and lands roughly 100ms after the failure, and the application keeps running in that window. The Command Log paints asynchronously too, so the error text can be missing as well.

open as a page

A retried Cypress test left three images in cypress/screenshots — which is the last attempt?

level: seniorimportance: should knowfreq 36%

basics

~20 s

Cypress appends (failed) to a failure capture and (attempt 2), (attempt 3) and so on to every attempt after the first, so the image carrying the highest attempt number is the attempt that finally ended the test.

open as a page

How far should a Cypress suite rely on `blackout` to keep customer data out of saved media?

level: principalimportance: should knowfreq 30%

basics

~20 s

Only as a tidiness measure on captures you ask for by name. Blackout is dropped for runner captures, and every automatic failure screenshot is a runner capture, so it never covers the image CI actually produces, and it never touches a video.

open as a page

In Cypress 16, what does `videoCompression` change about a spec's saved video?

level: middleimportance: nice to knowfreq 24%

basics

~20 s

It sets the Constant Rate Factor used to encode the recording. It defaults to false, which skips encoding and leaves a larger file. True means CRF 32; a number from 1 to 51 sets the CRF, where lower means better quality.

open as a page