Migrate mabl browser journeys to Monito

Move mabl browser journeys to Monito scenarios. Review export limits, map logins and schedules, and replace the CI trigger after checking the evidence.

mabl combines point-and-click and natural-language authoring with developer extensions. Source · checked 2026-10-23.

Start with the browser journeys you want to maintain as scenarios. Read the existing actions, assertions and setup before choosing what to move. Write down what you want to change about your workflow before recreating the journey. A different authoring tool does not remove the need to define the result or prepare the account that reaches it. Source · checked 2026-10-23.

Use an export as a review aid where it preserves the steps you need. Compare it with the original test before relying on it; an omitted step can carry a prerequisite or assertion. Our team wrote the step lists below as illustrative browser journeys, not exported mabl files. The benchmark runs cover comparable behavior and do not execute these examples. Source · checked 2026-10-23.

What the source documentation says

Point-and-click or natural language, with reusable JavaScript and Appium snippets and support for building on Playwright tests. Source · checked 2026-10-23.

Tests live in mabl. The CLI can export supported tests and steps, with documented exclusions. Source · checked 2026-10-23.

Custom quote with credits for cloud runs. Local runs are free; the page does not publish a dollar price. Source · checked 2026-10-23.

mabl tests export --format writes yaml (the default), json, csv, playwright (TypeScript) or side (Selenium IDE). Playwright and Selenium IDE export only support browser tests. Source · checked 2026-10-23.

Only user-generated tests can be exported; mabl-generated visit home page, link crawler and visual smoke tests are excluded. Playwright and Selenium exports exclude select steps, drag and drop steps, JavaScript snippets, API steps, cookie interactions, file uploads, download assertions, accessibility checks, MFA authenticator steps, email testing and PDF testing. Selenium exports do not support conditional steps. Source · checked 2026-10-23.

What translates and what changes

mabl concepts mapped to Monito
	mabl	Monito
Browser steps and assertions	Point-and-click or natural language, with reusable JavaScript and Appium snippets and support for building on Playwright tests. Source · checked 2026-10-23.	Put each required outcome in What to test. Preserve arithmetic and reload checks. Reaching a page or seeing a toast does not prove the saved state. Read the original steps as well as the export. Keep executable setup outside the scenario when it cannot be expressed as a browser outcome.
Exported tests	mabl tests export --format writes yaml (the default), json, csv, playwright (TypeScript) or side (Selenium IDE). Playwright and Selenium IDE export only support browser tests. Source · checked 2026-10-23.	Rewrite the browser behavior as scenario text. Keep the export as a reference; Monito does not import a mabl project or execute exported framework code.
Steps missing from code exports	Only user-generated tests can be exported; mabl-generated visit home page, link crawler and visual smoke tests are excluded. Playwright and Selenium exports exclude select steps, drag and drop steps, JavaScript snippets, API steps, cookie interactions, file uploads, download assertions, accessibility checks, MFA authenticator steps, email testing and PDF testing. Selenium exports do not support conditional steps. Source · checked 2026-10-23.	Inventory each excluded step in the original test. Recreate the prerequisite in your own setup or keep that check in a tool that supports it. Do not discard an assertion because it is absent from an export.
Logins and authenticator steps	Record the account and initial state each test needs. Check the original test for authenticator steps missing from a code export. Source · checked 2026-10-23.	Store email, password and any TOTP setup key in an environment login. Protected-preview request headers are also stored on the environment. These settings do not implement general prompt-variable substitution. Save the authenticator setup key in the login's Advanced settings. Monito generates TOTP when signing in. HOTP is not supported.
Start URL	Record the application URL, environment and starting path used by the selected journey.	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.
Schedules and deployment events	Plans run ad hoc, on a schedule or on a deployment event. Timer and schedule triggers do not support branched plan runs. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.	Monito offers a single us-east region and an hourly minimum schedule. Schedule presets are hourly, every 6 hours, daily and weekly, in UTC. Choose a replacement preset that meets your coverage requirement. Do not silently replace a shorter interval with daily coverage.
GitHub Action	The documented GitHub Action is mablhq/github-run-tests-action@v1. The Action fires a deployment event that runs matching plans in mabl's cloud. Plans must match the supplied application, environment and plan-label filters. It uses a CI/CD-integration API key stored as MABL_API_KEY. Source 1 · checked 2026-10-23. Source 2 · 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.
Alerts	List the people and destinations that receive failures for the plans you are moving.	Failed automated runs can email you when run-alert emails are enabled. Email is available on Free, Pro and Team; Slack notifications require Team. Failure emails go to your account's email address; turn them on or off under Settings, Run alerts. Connect Slack channels on Team.
Runner location	Record any network access or location requirement before moving the browser journey.	Runs execute in us-east. You cannot select multiple regions. An environment selects the target app and login, not the runner's region. Monito has no private-location worker.
Suite execution	Inventory which journeys share accounts or test data in the plans you run together.	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.
Run evidence	Keep the reports you use to review the original assertions and investigate failures.	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.

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.

Carry the login outcome out of the browser test

Before · text

Start URL: https://app.example.com/login
Preparation: supply the disposable QA account's email and password.
Enter the email in the Email field.
Enter the password in the Password field.
Click Sign in.
Assert that the account menu is visible on the dashboard.
Assert that Recent activity is visible.
Assert that no sign-in error is visible.

Illustrative mabl browser step list, not an export or API payload. The example account uses password login without an authenticator challenge. Inspect your original test for steps the code export excludes. 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.

A run of a comparable journey from our benchmark

Preserve the checkout total when a script cannot export

Before · text

Start URL: https://shop.example.com/catalog
Preparation: use the checkout account with an empty cart and a saved staging shipping address.
Click Add to cart for Test mug.
Open Checkout and choose the saved staging shipping address.
Click Review order.
Assert that the item and shipping charge are visible.
JavaScript step: compare the total with the item amount plus shipping.
Stop at review without placing the order.

Illustrative mabl step list with the purpose of a JavaScript step stated in prose. It is not executable mabl syntax. JavaScript snippets do not export to Playwright or Selenium. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

After · Monito scenario

Name: Checkout review includes delivery
Starting path: /catalog
Environment: Staging

Instructions: Use the checkout account's saved login, start with an empty cart, add the test mug and choose its saved staging shipping address. Open checkout review without submitting the order.

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

Read the original JavaScript step before removing it. The scenario checks displayed amounts; it does not execute the snippet. Confirm that the visible total covers the same business requirement. Keep a separate code assertion if the script also checks internal values that the browser cannot show. Reset the cart and prepare the saved staging address before validation, and keep the instruction to stop at review.

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.

Retain the profile assertion after reload

Before · text

Start URL: https://app.example.com/settings/profile
Preparation: sign in with a disposable profile account.
Confirm that its display name differs from Migration sample.
Set Display name to Migration sample.
Click Save.
Assert that the success notice appears and the member list updates.
Reload the page.
Assert that the display name remains Migration sample.

Illustrative mabl browser step list. Reset the account before each run. Review the original test when an export omits setup; this is not a mabl YAML or CSV format. 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.

Keep the assertion after reload even if the preceding steps already show a success notice. Restore the initial profile value before each validation run so the save changes something. If an API step or snippet prepared that account, keep equivalent setup in your own workflow. A saved login provides access; it does not replace that setup or prove that an omitted export step was unnecessary.

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

Inventory the selected tests, their plan triggers, expected results and prerequisites. Use mabl tests export for reference where useful, then compare the export with the original test. Record excluded steps and mabl-generated tests separately so they cannot disappear from the coverage review. Source · checked 2026-10-23.
Create a Monito environment, saved logins and a suite for the moved journeys. Recreate the observable actions and outcomes. Keep executable setup and unsupported checks in their existing tools. Run both versions against the same build, inspect their reports and investigate disagreements, including cannot-verify results.
Replace mablhq/github-run-tests-action@v1 for the moved journeys with the blocking project run step below, after successful deployment. Use the generated GitHub Actions authentication setup under Automations. Set PROJECT_ID to the destination project. Set SUITE_NAME to the suite containing the migrated journeys. Keep the mabl Action and MABL_API_KEY for plans you retain there; that key does not authenticate Monito. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.
After validating the replacement deployment run, remove the moved tests from mabl plans that deployment events trigger, or turn off those plans' Deployment trigger. A retained mabl Action still runs plans matching its application, environment and plan-label filters. Leaving moved tests in those plans keeps running them in mabl's cloud on matching deployments, spending mabl credits and producing duplicate verdicts. Keep Deployment triggers enabled for plans whose tests still need to run in mabl. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23. Source 3 · checked 2026-10-23. Source 4 · checked 2026-10-23.
Create the replacement schedule with the intended environment and suite, then check run-alert emails and Slack destinations. After the first green Monito run from the replacement trigger, inspect its evidence and turn off the old schedules for the moved checks. Keep retained plans and their triggers active. Compare the resulting coverage with the original schedule before calling the cutover complete. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

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 when every test that didn't pass errored for a reason Monito caused, or when the CLI stops before it collects every result; 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 fire a deploy webhook for the same deployment unless you intend duplicate runs. An asynchronous webhook is an alternative when the pipeline does not need to wait for a verdict.

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 mabl fits better

Choose mabl when QA and business users need point-and-click authoring, while developers extend the tests with JavaScript, Appium or Playwright. Source · checked 2026-10-23.

Choose mabl when accessibility and performance testing belong in the same evaluation as browser checks. Its pricing page includes those capabilities and lists mobile testing as an add-on. Source · checked 2026-10-23.

Choose mabl when exporting supported browser steps to Playwright or Selenium IDE matters. Evaluate the documented exclusions against your own tests first. Source · checked 2026-10-23.

What to keep outside this migration

Move selected browser journeys with observable outcomes. Keep JavaScript setup, API, mobile, accessibility and performance coverage in the tools that already supply it. A browser scenario does not replace all the work in a mabl plan.

Keep exported code when maintaining that artifact is the requirement. Monito runs desktop Chromium. It does not run component tests, provide multiple browser engines or export executable test code.

If your journey also needs an email inbox supplied by the testing vendor, Monito does not provide one. Its disposable inbox login requires your own Resend receiving domain and account. An inbox step later in the journey needs another tool.

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.

Create a scenario All switching playbooks