Migrate Cypress browser journeys to Monito

Move brittle Cypress browser journeys to Monito with JavaScript conversions, saved logins and a CI cutover. Keep component, API and isolated tests.

Cypress combines JavaScript and TypeScript tests with Studio AI recording and natural-language tooling. Source · checked 2026-10-23.

Move the end-to-end journeys you no longer want to maintain as Cypress specs. Signup, login, checkout, onboarding and settings persistence can become scenarios with visible outcomes. Keep unit, component, API and fast isolated tests in Cypress or your existing unit runner. Retain useful browser specs when direct control over commands is still a requirement.

Start with the assertions and prerequisites, not a bulk rewrite of cy.get calls. A fixture, intercepted request or session helper can hide setup the new scenario still needs. Our team wrote the JavaScript specs below as illustrative conversions. Replace their app-specific selectors, paths and fixture data before using them. The reports are comparable benchmark runs, not results from these examples.

What the source documentation says

JavaScript or TypeScript specs, with Studio AI recording and natural-language steps through cy.prompt. Source · checked 2026-10-23.

Code in your repo. You can export generated commands into version-controlled tests or keep natural-language steps. Source · checked 2026-10-23.

With cy.prompt left in the test, Cypress says it regenerates a step when cached selectors fail. Exported test code remains something your team maintains. Source · checked 2026-10-23.

cy.prompt is in beta, Chromium-only and requires a Cypress Cloud account or record key. Source · checked 2026-10-23.

What translates and what changes

Cypress concepts mapped to Monito
 CypressMonito
Test file or specCode in your repo. You can export generated commands into version-controlled tests or keep natural-language steps. Source · checked 2026-10-23.Name a scenario for each selected user journey and describe its actions and expected result. There is no Cypress spec importer or executable code export.
LocatorsThe examples use cy.get for app-specific selectors and cy.contains for visible button text. Source · checked 2026-10-23.Describe what you want to operate using its visible label and context. Keep distinctions such as which product to add and which settings form to save.
AssertionsThe should assertions below check the page state, checkout values and saved profile. Source · checked 2026-10-23.Write the required result in What to test. Preserve the total calculation and the state after reload. Do not replace a persistence assertion with a success notice.
Fixtures and cy.sessionInventory fixtures, account setup and any cy.session helper used by the selected specs.Store email, password and any TOTP setup key in an environment login. Protected-preview request headers are also stored on the environment. There is no import of fixture files or cy.session state.

Select the login role in each scenario. Recreate data preparation separately. A saved login does not execute a Cypress fixture or cy.session callback.

Base URLRecord the baseUrl used by cy.visit and any CI configuration override.Create the environment with your app's base URL and set the scenario's starting path. Use --base-url on project run for a deployed preview. A preview URL does not authorize sending saved logins to a new origin; use an approved origin for an authenticated journey.
Retries and flake handlingInventory retries and Cloud flake reports before replacing these specs. Source · checked 2026-10-23.The agent chooses browser actions during each run. It can retry an inconclusive action within bounded limits and recover from transient model-provider errors while time remains. A measured mismatch of required behavior is a failure to report, not a reason to retry until green. Missing access or evidence remains an error. Read the report before rerunning; do not weaken the expected outcome to hide a failure.

Do not transfer a retry-until-pass policy into the expected result. Review whether the report found a product failure or a missing prerequisite.

CI jobRun from your CI pipeline. Cloud adds parallel orchestration and PR status feedback. Source · checked 2026-10-23.A deploy webhook queues runs after deployment. For a blocking GitHub check, use the documented CLI project run workflow. Both integrations require Pro or Team.
Videos and screenshotsPreserve the debugging artifacts your current Cypress job retains before retiring its migrated specs.Read the run report's measured checks, screenshots, network and console evidence. Recording is off for signed-in runs; masked screenshots are captured instead. Keep old traces, videos and screenshots separately; a new scenario starts its own run history.
Parallel shardingRun from your CI pipeline. Cloud adds parallel orchestration and PR status feedback. Source · checked 2026-10-23.Suite members launch side by side, with up to 5 launches in progress at once. This limits launch work, not the number of already running browsers. You do not configure CI shards. Give each journey independent test data so concurrent runs cannot overwrite the same cart or profile.

Set up the scenario and its login

Create a project and an environment with your app's base URL. Give the scenario a Name and a Where value, either a starting path or a full URL. In What to test, put the instructions and expected outcome together. The examples separate those two parts for review; they are not an import file or separate required form fields. Select the environment you intend to run against. Replace the illustrative paths, account names and fixture data with values your application actually has.

Add the email and password as an environment login, then select its role in the scenario. For authenticator login, open Advanced and save the setup key; Monito generates the TOTP code during sign-in. Login secrets stay encrypted in server storage. Protected-preview request headers also belong on the environment, with encrypted values tied to its origin. These settings do not implement general prompt-variable substitution. A disposable email login needs your own Resend receiving domain, API key, expected sender and subject prefix. It reads a code or magic link for a new disposable address, not an existing fixed-email account.

Writing a scenario

Three converted browser journeys

These examples show how to rewrite intent. Each report link is a run of a comparable journey from our benchmark. It is not a run of your check or a validation of these illustrative configurations.

Sign in and reach the account dashboard

Before · js
describe('account dashboard access', () => {
  it('signs in with the QA account', () => {
    cy.visit('/login');
    cy.env(['QA_EMAIL', 'QA_PASSWORD']).then(({ QA_EMAIL, QA_PASSWORD }) => {
      cy.get('input[name="email"]').type(QA_EMAIL, { log: false });
      cy.get('input[name="password"]').type(QA_PASSWORD, { log: false });
      cy.contains('button', 'Sign in').click();
    });

    cy.location('pathname').should('eq', '/dashboard');
    cy.get('[data-cy="account-menu"]').should('be.visible');
    cy.contains('h2', 'Recent activity').should('be.visible');
    cy.get('[data-cy="login-error"]').should('not.exist');
  });
});

Illustrative Cypress JavaScript spec using built-in commands. Configure baseUrl and supply QA_EMAIL and QA_PASSWORD in the Cypress test environment. These credentials are read with cy.env(). Keep test isolation enabled. This example account has no authenticator challenge. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

After · Monito scenario
Name: Account dashboard access
Starting path: /login
Environment: Staging

Instructions: Sign in with the saved QA login and open the account dashboard.

Expected: The account menu and recent activity are visible. A sign-in error or unresolved login challenge does not pass.

Store the email and password in an environment login. When the sign-in challenge itself is under test, select Start logged out under Options, or leave Reuse login sessions off on the login. Session reuse is off by default. If your real account needs an authenticator code, save its setup key and describe that challenge too. The benchmark below demonstrates a blocked prerequisite, not successful authentication.

The run ended with an Error status, which our benchmark scores as cannot verify: the security check failed and no credentials were supplied. It illustrates an unresolved login prerequisite, not a successful sign-in or proof that your authentication will work.

Check that the checkout total includes shipping

Before · js
describe('checkout review', () => {
  it('includes delivery in the total', () => {
    cy.visit('/catalog');
    cy.get('[data-cy="cart-empty"]').should('be.visible');
    cy.contains('[data-cy="product"]', 'Test mug').within(() => {
      cy.contains('button', 'Add to cart').click();
    });
    cy.contains('a', 'Checkout').click();
    cy.fixture('shipping.json').then((shipping) => {
      cy.get('[name="address"]').type(shipping.address);
      cy.get('[name="city"]').type(shipping.city);
      cy.get('[name="postalCode"]').type(shipping.postalCode);
    });
    cy.contains('button', 'Review order').click();
    cy.get('[data-cy="order-items"]').should('contain.text', 'Test mug');
    cy.get('[data-cy="order-summary"]').should(($summary) => {
      const subtotal = $summary.find('[data-cy="subtotal"]');
      const shipping = $summary.find('[data-cy="shipping"]');
      const total = $summary.find('[data-cy="total"]');
      expect(subtotal).to.be.visible;
      expect(shipping).to.be.visible;
      expect(total).to.be.visible;
      expect(subtotal.attr('data-cents')).to.match(/^\d+$/);
      expect(shipping.attr('data-cents')).to.match(/^\d+$/);
      const expected = Number(subtotal.attr('data-cents')) + Number(shipping.attr('data-cents'));
      expect(total.attr('data-cents')).to.equal(String(expected));
    });
    // Stop at review. Do not submit the order.
  });
});

Illustrative Cypress JavaScript spec for guest checkout. Configure baseUrl, an empty cart and shipping.json with address, city and postalCode fields. The app exposes monetary values as integer data-cents attributes. Source · checked 2026-10-23.

After · Monito scenario
Name: Checkout review includes delivery
Starting path: /catalog
Environment: Staging

Instructions: Start with an empty cart, add the test mug and enter address 1 Test Street, city Testville, postal code 00000; replace these placeholders with your shipping.json values. Open checkout review without submitting an order.

Expected: The review contains the item and shipping charge, and the displayed total equals their sum.

Copy the non-secret shipping fixture values into the scenario and keep the stop-at-review instruction. The spec checks app-specific amount attributes; the scenario checks displayed amounts. Validate that these describe the same requirement. If the existing test relies on an intercepted response, decide whether the deployed app can supply equivalent test data. Keep that isolated test in Cypress when the mocked behavior itself is what you need to cover.

The benchmark includes a working checkout and a cart whose total omits shipping. These reports exercise checkout behavior and arithmetic. They do not execute the illustrative example above.

Save a profile change and verify persistence

Before · js
describe('profile persistence', () => {
  beforeEach(() => {
    cy.session('profile-qa', () => {
      cy.visit('/login');
      cy.env(['PROFILE_EMAIL', 'PROFILE_PASSWORD']).then(({ PROFILE_EMAIL, PROFILE_PASSWORD }) => {
        cy.get('input[name="email"]').type(PROFILE_EMAIL, { log: false });
        cy.get('input[name="password"]').type(PROFILE_PASSWORD, { log: false });
        cy.contains('button', 'Sign in').click();
        cy.location('pathname').should('eq', '/dashboard');
      });
    });
  });

  it('keeps the display name after reload', () => {
    cy.visit('/settings/profile');
    cy.get('[name="displayName"]')
      .should('not.have.value', 'Migration sample')
      .clear().type('Migration sample');
    cy.contains('button', 'Save').click();
    cy.get('[role="status"]').should('have.text', 'Profile saved');
    cy.get('[data-cy="member-list"]').should('contain.text', 'Migration sample');

    cy.reload();
    cy.get('[name="displayName"]').should('have.value', 'Migration sample');
    cy.get('[data-cy="member-list"]').should('contain.text', 'Migration sample');
  });
});

Illustrative Cypress JavaScript spec with cy.session. Configure baseUrl and supply PROFILE_EMAIL and PROFILE_PASSWORD in the Cypress test environment for a disposable profile account. These credentials are read with cy.env(). Reset its display name to a different value before each run; session caching does not reset profile data. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

After · Monito scenario
Name: Display name survives reload
Starting path: /settings/profile
Environment: Staging

Instructions: Use the disposable profile account's saved login, starting with a different display name. Change it to Migration sample, save, inspect the member list and reload.

Expected: The success notice appears, the member list updates and Migration sample remains the display name after reload.

Replace the session helper with a selected environment login. Keep the account reset in your own setup and preserve the assertion after reload. A cached login and a saved profile are different state. The failure benchmark shows why a success toast cannot replace the persistence check, even when the member list initially appears to update.

The benchmark profile saves show both a persistent update and an update lost after reload. The latter still shows a success toast. Read the reload evidence before treating the visible confirmation as success.

Ask your coding agent to recreate the checks

You can ask your coding agent to recreate the checks through the hosted MCP server. Give it the public target URL, environment and non-secret intent. The check tool runs a URL and expectation. After reviewing the result, save_check saves that check under a name without starting another run. Use run_scenario for the saved scenario afterward. A check or run_scenario call spends credits. These tools do not import the source vendor's project.

Connect the hosted MCP server and provide the journey you reviewed above.

Agent prompt
Recreate this browser journey in Monito using the hosted MCP server. Use the intended project's environment and saved login. Call check with the public URL and the instructions plus expected outcome. Read the report and identify any missing prerequisites. If the scenario is correct, call save_check with its checkId and name. Use run_scenario with the saved scenarioId for subsequent runs. Keep credentials out of the expectation.

Cut over the trigger and schedule

  1. Select the full-browser journeys to move and inventory their assertions, fixtures, session helpers and intercepted requests. Keep unit, component, API and fast isolated tests in Cypress or your existing unit runner. Keep browser specs that still need direct command control.
  2. In your Monito project, create a suite containing the migrated journeys. Set up the target environment and saved logins. Prepare independent data for each scenario. Recreate the observable actions and outcomes, then run each scenario manually and inspect its evidence against the old spec.
  3. Run the Cypress specs and Monito scenarios against the same deployed build while validating the replacement. Investigate differing verdicts and missing prerequisites. Check a known broken outcome before removing the matching spec from the old CI selection.
  4. Replace the Cypress e2e job for the moved journeys with the blocking project run step below, after successful deployment. Configure GitHub Actions under Automations and use its generated authentication setup. Set PROJECT_ID to the project holding those scenarios. Set SUITE_NAME to the suite containing the migrated journeys. Keep the rest of the suite running, including fixture preparation and Cypress Cloud recording for retained specs when you still need it. Source · checked 2026-10-23.
  5. Remove only the migrated specs from the old job once you have reviewed reports from the new trigger. Keep old artifacts for reference. Add recurring checks with the schedule presets below if deployment-only coverage leaves a gap you need to monitor.

For asynchronous checks, the deploy webhook returns 202 when runs are queued. That response does not mean they passed. Results appear in the dashboard; this request does not block the pipeline for a verdict. Deploy webhooks require Pro or Team.

For a blocking pipeline, configure GitHub Actions under Automations and use its generated authentication setup before adding this run step. Set GITHUB_TOKEN and grant checks: write. PROJECT_ID identifies the Monito project; PREVIEW_URL is the deployed target. The CLI waits for results and exits with code 1 if a scenario fails or errors. --github-check publishes the Monito GitHub check; the check is neutral only when every non-passing result is an error Monito caused; other errors and failures mark it failed. The CLI exits 1 either way. The example pins the published CLI 4.8.1. A preview URL does not authorize sending saved logins to a new origin; use an approved origin for an authenticated journey.

Blocking GitHub check · shell
npx -y @monitodev/cli@4.8.1 project run "$PROJECT_ID" \
  --base-url "$PREVIEW_URL" --wait --github-check --suite "$SUITE_NAME"

Follow the GitHub Actions setup for authentication and permissions. The project run reference documents the command. GitHub Actions requires Pro or Team.

Without --suite, the command runs every scenario in the project, or the suite selected on the GitHub Actions automation. Pass --suite <name> or select a suite on the automation to limit it to the migrated journeys. Do not also trigger the same checks through a deploy webhook unless duplicate runs are intentional. Retained specs that record to Cypress Cloud, use its parallel orchestration or call cy.prompt still need your Cloud setup. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

Schedule allowance, regions and alerts

Schedule presets are hourly, every 6 hours, daily and weekly, in UTC. Runs execute in us-east; there is no region selector or multi-region execution. Failed automated runs can send email when run-alert emails are enabled. Email is available on Free, Pro and Team. Slack notifications require Team. Check the chosen environment, suite and notification preferences before relying on the schedule.

50 free test credits every month. Your balance refills to 50 on the 1st of each month (UTC), counting credits reserved by running tests. Unused credits are not added again; purchased credits are kept. Your signup credits count as the first month. Free includes one daily schedule. Verify your email to receive monthly refills. Any schedule other than that one daily schedule, a deploy webhook, GitHub Actions, and a public status page need Pro.

Check pricing before enabling the recurring workload. A slower schedule leaves a longer gap between checks; it changes the coverage you are buying.

When staying on Cypress fits better

Choose Cypress when you already own its specs and want to keep them as code, including code generated from natural-language steps. Source · checked 2026-10-23.

Choose Cypress when you need component tests that mount the component directly in a real browser. Source · checked 2026-10-23.

Choose Cypress when your team wants CI orchestration and failure feedback around its existing suite, including parallel runs and flake detection. Source · checked 2026-10-23.

What to keep outside this migration

Keep unit, component, API and fast isolated tests in Cypress or your existing unit runner. Move only brittle full-browser journeys such as signup, login, checkout, onboarding and settings persistence when their expected outcomes are observable.

Monito runs desktop Chromium. It does not run component tests, provide multiple browser engines or export executable test code. Keep Cypress when you need the committed spec and direct control over its commands.

Keep fixture callbacks, request interception and isolated assertions in code when the test depends on them. Recreating a browser journey does not reproduce a mocked environment, an entire suite or the old report history.

Validate your first scenario

Run the scenario against your own app and inspect the result before switching its trigger. Our team publishes the benchmark method and its limits on the reliability page. The reports above show comparable behavior; your application still needs its own validation.