A failed assertion stops the remaining commands in that same Cypress test. To get later checks reported independently, put them in separate it tests. To handle a possibly temporary failure, configure test retries—but Cypress reruns the whole test, not just the failed command. After a test fails and exhausts its retries, Cypress normally moves on to the remaining tests; a failed shared hook can prevent dependent tests from running.
What “continue after a check fails” means in Cypress
There are three different behaviors that are easy to confuse: Cypress retrying an assertion while it waits for the page, Cypress rerunning an entire failed test, and Cypress proceeding to another test after the current test has failed. They solve different problems.
| Behavior | What Cypress repeats or continues | When it helps |
|---|---|---|
| Assertion/query retry | Retries a linked query and its assertion while the assertion is pending. | A page condition may become true after a short wait. |
| Test retry | Starts the failed test again from the beginning, including its beforeEach and afterEach hooks. |
A failure may be intermittent and another complete attempt is useful. |
| Suite progression | Moves to remaining tests after a test has failed and used its configured attempts. | You want the run to collect results for other tests. |
None of these makes Cypress resume later statements in a test body after a final assertion failure. Cypress documents query retry behavior in Retry-ability in Cypress and whole-test reruns in Test retries in Cypress.
Run independent checks in separate tests
If you want both the page-title check and the submit-button check to appear in the results even when one fails, give each check its own it block. Cypress treats the tests as separate outcomes; failure of one test does not stop the runner from proceeding to the next test once any configured retries are exhausted.
describe('Checkout page', () => {
beforeEach(() => {
cy.visit('/checkout')
})
it('shows the expected page title', () => {
cy.title().should('equal', 'Checkout')
})
it('enables the submit button', () => {
cy.get('[data-testid="submit-order"]').should('be.enabled')
})
})Use this structure when the checks can stand on their own. Each test gets its own result, so a title mismatch does not suppress the button test. Cypress recommends organizing tests around independent behavior; see Writing and organizing Cypress tests.
Keep test setup independent too
Separate test bodies are not enough if both depend on a shared setup hook. In the example, a failed beforeEach visit or other setup command can prevent the test from reaching its assertions. A failure in a before or after hook also does not receive the normal test-retry behavior described for test failures. Keep shared setup reliable, and avoid making one test depend on mutable state left by another.
Understand assertion retry-ability
Cypress retries linked queries and assertions until they pass or time out. For example, cy.get(...).should(...) can keep querying for the element and reevaluating the assertion while Cypress is waiting. The documentation summarizes this as: “Queries link up, retrying the entire chain together.” That is waiting for the expected condition; it is not a way to proceed to the next command after Cypress has declared the assertion failed.
cy.get('[data-testid="status"]')
.should('have.text', 'Ready')
cy.get('[data-testid="submit-order"]')
.should('be.enabled')If the status assertion passes before its timeout, the next command runs. If it fails finally, the test fails at that point and the later button assertion in this same test does not run. When both results matter independently, use separate tests rather than trying to turn a failed assertion into a non-fatal check.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteRetry the whole test for suspected flakiness
Test retries are disabled by default. Set a retry count when the failure may be intermittent and rerunning the complete test is useful—not to hide deterministic product defects. A configured count of two means up to three total attempts: the initial attempt plus two retries. Each attempt starts over, so its setup and actions must tolerate repetition. Cypress’s test-retry guide describes retry configuration and behavior.
import { defineConfig } from 'cypress'
export default defineConfig({
retries: {
runMode: 1,
openMode: 0,
},
})This configuration allows one additional attempt during cypress run and none during cypress open. Put it in the Cypress configuration file used by your project. Choose values deliberately: a retry reruns the test and its beforeEach and afterEach hooks, so the run takes longer and non-idempotent actions may be repeated. Failures in before and after hooks do not trigger test retries.
When a retry is appropriate
- Use retries for suspected intermittent behavior where another full attempt can give useful signal.
- Keep the test outcome visible. A retry is not proof that the underlying issue is fixed.
- Do not use retries as a substitute for separating independent assertions or correcting a consistently wrong expectation.
- Account for the extra execution time; Cypress notes that retries can increase test-run time in its test performance guidance.
Handle expected application exceptions narrowly
An uncaught application exception is different from a failed assertion. Cypress fails the currently running test when it detects an uncaught exception. If a particular exception is known and intentionally expected, a narrowly matched uncaught:exception handler can prevent Cypress from failing that test for that exception. Return false only for the expected error; let unexpected exceptions fail normally. See Common error messages in Cypress and the Catalog of Events.
it('continues for one known legacy exception', () => {
cy.on('uncaught:exception', (err) => {
if (err.message.includes('Known legacy widget error')) {
return false
}
// Returning nothing lets unexpected exceptions fail the test.
})
cy.visit('/page-with-legacy-widget')
cy.get('[data-testid="main-content"]').should('be.visible')
})Use cy.on for per-test handling; that listener is removed at the end of the test. By contrast, Cypress.on listeners persist until removed, so they require careful cleanup. Cypress commands and assertions are not supported inside these event callbacks. Suppressing a known exception does not make a failed assertion continue.
Choose the right approach
| Question | Recommended approach |
|---|---|
| Could the condition become true while Cypress is waiting? | Use a query-and-assertion chain and let assertion retry-ability do its job. |
| Should later checks get independent results even when one fails? | Put independent checks in separate it tests. |
| Could this whole test fail intermittently, and is rerunning it safe? | Configure a modest retry count and make setup and actions repeatable. |
| Is a specific uncaught application exception expected? | Match that known exception narrowly in a per-test handler; do not suppress unrelated errors. |
| Are several tests being skipped after shared setup fails? | Investigate the failing hook and dependencies; separate test bodies cannot bypass failed setup. |
Troubleshooting common “Cypress stopped” cases
Commands after an assertion do not run
This is expected after a final assertion failure. Cypress does not treat ordinary assertions as soft checks. Split checks that need independent outcomes into separate tests.
The same test runs again
Check the retries setting in the active Cypress configuration. Retries rerun the entire test, not just the failed assertion. Reduce or disable the setting if repeated attempts obscure a deterministic failure or cost too much time.
Other tests are skipped after a hook error
Find whether the error came from shared before or beforeEach setup. Tests that rely on setup which did not complete cannot safely continue as though the setup succeeded. Fix the hook or reduce unnecessary shared dependencies instead of expecting separate it blocks to override it.
An application exception is still failing the test
Confirm the handler is registered for the relevant test and matches the exact known error condition. Avoid a blanket handler that returns false for every exception: that can conceal real application failures. Also keep Cypress commands out of the event callback.
Recommended Free Tools
A retry makes the problem appear intermittently
Treat that as evidence to investigate, not as a pass that establishes correctness. Review whether each attempt begins in a known state and whether setup, submissions, or other side effects can safely happen more than once.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Or skip the browser setup
If the task is to capture a clean screenshot of a page as test evidence rather than to continue Cypress assertions, ScreenshotNeo offers a separate website screenshot API. It accepts a URL and returns a screenshot or PDF; it does not change Cypress test failure behavior.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpSee the ScreenshotNeo documentation for API details. Before capture it accepts cookie or consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets; these steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. See ScreenshotNeo for the service. Sign up free for 1,000 screenshots a month, with no card required.
Frequently Asked Questions
Does Cypress continue to the next test after one fails?
Yes. After the current test has exhausted its configured retries, Cypress proceeds to remaining tests unless a failure in shared setup or another hook prevents dependent tests from running.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Does setting retries to 2 mean two attempts total?
No. It means two additional attempts after the initial attempt, for up to three total executions of the test.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
