Migrate Reflect browser tests to Monito

Move Reflect recordings to Monito scenarios with saved logins, schedule mapping and a CI cutover. Review benchmark evidence and SmartBear tradeoffs.

SmartBear Reflect offers browser recording, plain-English prompts and agent authoring through MCP. Source · checked 2026-10-23.

Start with the Reflect tests whose recorded targets you keep repairing. Read the actions and assertions, including any AI Prompt steps, and write down the user outcome they protect. Reflect already supports plain-English authoring, so the decision is whether you want to move this browser coverage and its workflow, not whether to add prompts for the first time. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23. Source 3 · checked 2026-10-23.

Work from the tests you can inspect in Reflect. Its documentation does not establish an export to runnable framework code. Our team uses illustrative step lists below rather than inventing an export format. Keep screenshots or notes of the original assertions and setup while you validate the replacement. The benchmark links show comparable behavior, not execution of a Reflect export. Source · checked 2026-10-23.

What the source documentation says

Record actions in a browser, write plain-English prompts or author through agents using MCP. Source · checked 2026-10-23.

Tests live in Reflect's cloud. Its documentation does not establish an export to runnable framework code. Source · checked 2026-10-23.

Reflect records several selectors for each element and tries them in order of specificity to make tests resilient. Source · checked 2026-10-23.

Credit allowances vary by plan and test type. Dollar prices require a sales conversation. Source · checked 2026-10-23.

A 14-day trial with unlimited functionality. Tests can be scheduled from hourly to monthly. Source · checked 2026-10-23.

What translates and what changes

Reflect concepts mapped to Monito
 ReflectMonito
Recorded steps and selector targetsReflect records several selectors for each element and tries them in order of specificity to make tests resilient. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23. Source 3 · checked 2026-10-23.Describe the visible control and the action in plain English. Keep details that distinguish similar controls, such as the item name or the settings section.

If your retained notes include CSS or XPath targets, use them to identify the intended control rather than copying them as scenario instructions. Keep the actions and assertions from any AI Prompt step too.

AssertionsRead the required outcome of each recorded or prompted step, especially assertions after reload. 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.
Variables and login stepsInventory the credentials and test data supplied to login and later steps. Recover the account prerequisites before rewriting the flow.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 URLRecord the URL where the journey begins and the target your CI execution uses.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 intervalsA 14-day trial with unlimited functionality. Tests can be scheduled from hourly to monthly. 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 Hourly on Pro or Team when retaining hourly coverage. There is no monthly preset; do not replace an existing monthly check with a more frequent schedule without reviewing the workload.

CI action or API triggerExecute a suite with POST https://api.reflect.run/v1/suites/<suite-id>/executions and an x-api-key header. 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.
AlertsRecord who responds to a failed suite and where they currently receive its result.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.
Private locationsCheck whether your suite depends on a private environment before changing its runner.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 executionCI calls the Reflect API to execute a suite. The docs provide recipes for GitHub Actions, GitLab, Azure Pipelines and other providers. 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.
Run evidencePreserve the reports your team currently uses to debug these recorded journeys.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.

Turn the recorded login into an explicit outcome

Before · text
Start URL: https://app.example.com/login
Preparation: supply the disposable QA account's email and password.
Enter the email in the recorded Email field.
Enter the password in the recorded Password field.
Click the recorded Sign in button.
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 Reflect recorded step list. This is not an export format or API payload. The example account uses password login without an 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.

Carry checkout assertions out of the recording

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 the recorded Add to cart button for Test mug.
Open Checkout.
Choose the saved staging shipping address.
Click Review order.
Assert that the item and shipping charge are visible.
Assert that the total equals the item amount plus shipping.
Stop before placing the order.

Illustrative recorded step list. The same required outcomes could be written as prompts; this list does not imply a downloadable Reflect test format. 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.

Write the arithmetic requirement alongside the actions. A list that ends at Review order would discard the assertion that catches missing shipping. Keep the stop-before-payment boundary and prepare the saved staging address in advance. Use a separate checkout account and reset its cart so another suite member cannot change the amount while this journey runs.

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.

Keep the profile check beyond the success notice

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

Illustrative Reflect recorded step list. Reset the account before each validation run. The list records intent and expected results, not internal selector or export fields. 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 reload even if you originally added it only after finding a persistence bug. A repaired selector proves that the test found the control; it does not prove that Save stored the value. Reset the account outside the scenario before later runs. Compare both tools against the saved state rather than deciding by the presence of a success toast.

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. Inspect the selected Reflect tests and suites. Record the actions, assertions, start URLs, login prerequisites and schedules. Keep the original tests during validation; the documented API execution workflow is not evidence of an export format. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23. Source 3 · checked 2026-10-23.
  2. Create a Monito environment and saved logins, then a suite containing only the moved journeys. Recreate the instructions and expected outcomes. Run the recording and scenario against the same build, read both reports and resolve missing prerequisites before adding CI.
  3. Find the CI call POST https://api.reflect.run/v1/suites/<suite-id>/executions, authenticated with an x-api-key header. Replace that call for the moved checks 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 Reflect API call for suites you retain there; its key does not authenticate Monito. Source · checked 2026-10-23.
  4. 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 ownership of the retained Reflect suites and their alerts explicit. Source · 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 Reflect fits better

Choose Reflect when testers want to record a flow in a cloud browser. Its recorder opens an interactive browser session and shares it with the test author. Source · checked 2026-10-23.

Choose Reflect when you need multiple web browsers, native mobile on real devices, or SAP and Salesforce testing. Monito's runner is desktop Chromium. Source · checked 2026-10-23.

Stay with Reflect when it belongs to the SmartBear suite your team already uses, including test management in Zephyr. Moving selected browser journeys does not migrate those manual cases or the workflow around them. Retain that setup when keeping test management and execution together matters more than changing the browser scenario authoring. Source · checked 2026-10-23.

What to keep outside this migration

Move only the browser journeys you can inspect and validate. Keep Reflect when your SmartBear suite, test management workflow or cloud recording process is part of the requirement.

Monito runs desktop Chromium. Keep native mobile, multiple-browser and other platform coverage in Reflect when you rely on it. A rewritten browser scenario does not replace that coverage.

Reflect publishes no export format and no dollar prices, so plan to recreate the tests from their steps and ask SmartBear for pricing. Monito has no private-location worker; retain private-environment checks in a tool that supplies the access they need.

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.