Migrate TesterArmy tests to Monito

Move TesterArmy journeys before January 15, 2027. Map plain-English steps to Monito scenarios, or follow e2e's own guide into the repository.

TesterArmy is sunsetting. New sign-ups are closed. Existing accounts keep working until January 15, 2027. Next up is e2e. Source · checked 2026-11-05.

Existing TesterArmy accounts keep working until January 15, 2027, and new sign-ups are closed. Pick a destination before that date. e2e publishes the path from the hosted product into TypeScript tests in the repository. This playbook is the path to Monito. It is not a substitute for e2e's guide. Source 1 · checked 2026-11-05. Source 2 · checked 2026-11-05.

A saved TesterArmy test is a list of plain-language steps run in TesterArmy's cloud. A Monito scenario is the actions and the expected result, plus a starting path and an environment. The step lists below are illustrative. They are not an export from a customer project. Source · checked 2026-11-05.

Monito vs TesterArmy, including the sunset and the pre-sunset price list

Have the first scenarios converted

Email the scenarios to bartosz@monito.dev. Our team converts the first 5 for free. There is no call.

This is one destination. e2e publishes its own migrate guide for teams that want the tests in the repository. The sources above link it.

What the source documentation says

The seed post published 2026-11-03 says TesterArmy is now e2e, announces an $8 million seed, and says the TesterArmy platform stays available until January 15, 2027. It says e2e cloud is launching next year. It does not list a price for that cloud. Source · checked 2026-11-05.

e2e.com says TesterArmy does not use e2e underneath and that they are separate products. e2e is an open-source TypeScript runner under Apache-2.0. Source · checked 2026-11-05.

e2e's migrate guide turns hosted TesterArmy tests into TypeScript tests in the repository. Each enabled step becomes an awaited call. The guide is the path from TesterArmy to e2e. Source · checked 2026-11-05.

pricing.md lists Hobby at $99/month for 250 runs and Startup at $299/month for 1000 runs, plus 5 free runs for a new team. Yearly billing is listed at 15% off. Source · checked 2026-11-05.

What translates and what changes

TesterArmy concepts mapped to Monito
 TesterArmyMonito
Plain-language stepsA TesterArmy saved test is a list of plain-language steps that a QA agent runs in TesterArmy's cloud. Source 1 · checked 2026-11-05. Source 2 · checked 2026-11-05.Name the scenario. Put the actions and the expected result together in What to test. Select the environment and starting path separately.
Schedulese2e's migrate guide maps a TesterArmy group schedule to a scheduled CI workflow. Source · checked 2026-11-05.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 the old cadence was hourly or faster. Daily is a coverage change, not an equivalent replacement for a shorter interval.

Pull request checksThe TesterArmy homepage lists pull request checks that test every GitHub deployment before merge. Source · checked 2026-11-05.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.

The deploy webhook queues runs and does not block the deploy. A blocking GitHub Actions run fails the job when a scenario fails or errors.

Login, OAuth and OTPThe TesterArmy homepage lists authentication support for login flows, OAuth and OTP verification. Source · checked 2026-11-05.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.

Screenshots and recordingsThe TesterArmy homepage lists screenshots and recordings as visual evidence for every test run. Source · checked 2026-11-05.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.

Sign in and reach the account dashboard

Before · text
Project URL: https://app.example.com
Step (login): Log in as the QA admin.
Step (act): Open the account dashboard.
Step (assert): The account menu and recent activity are visible.
Step (assert): No sign-in error is visible.

Illustrative plain-language steps in the shape e2e's migrate guide documents (login, act, assert). Replace the account and the outcome. This is not a TesterArmy export. Source 1 · checked 2026-11-05. Source 2 · checked 2026-11-05.

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 on the Staging 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. TesterArmy does not return the password through its migrate tools, so set the secret in Monito yourself. A blocked challenge leaves this journey unverified.

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.

Review checkout without placing an order

Before · text
Project URL: https://shop.example.com
Preparation: checkout account, empty cart, saved staging shipping address.
Step (login): Log in as the checkout account.
Step (act): Add the test mug and open checkout review. Do not place the order.
Step (assert): The review shows the item and a shipping charge.
Step (assert): The displayed total equals the item amount plus shipping.

Illustrative plain-language steps. The arithmetic line is the required outcome. It does not invent a TesterArmy assertion field. Source · checked 2026-11-05.

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.

Keep the arithmetic requirement in the expected result. Reaching checkout is not enough. Reset the cart before each validation run and give checkout its own account so another scenario cannot change the same cart.

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 · text
Project URL: https://app.example.com
Preparation: disposable profile account whose display name is not Migration sample.
Step (login): Log in as that account.
Step (act): Set the display name to Migration sample, save, and reload.
Step (assert): A success notice appears and the member list updates.
Step (assert): Migration sample is still the display name after reload.

Illustrative plain-language steps. Reset the display name before each run so the save changes something. Source · checked 2026-11-05.

After · Monito scenario
Name: Profile name persists
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: A success notice appears and the member list shows Migration sample. The same name remains after reload.

A success notice does not prove the server stored the name. Keep the reload in the instructions and the persisted name in the expected result. Reset the starting name before the next validation run.

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. Read each TesterArmy test you still need and copy its plain-language steps, login, schedule and pull-request setting. Leave the originals in place. New sign-ups are closed, and existing accounts stop on January 15, 2027. Source 1 · checked 2026-11-05. Source 2 · checked 2026-11-05.
  2. Create the Monito environment and saved logins, then one scenario per journey. Run it and read the report before you add a trigger. A pass, a fail and an error are different. An error means the run could not verify the scenario.
  3. For a check that must fail the pull request, replace that TesterArmy pull-request check with the blocking project run below, after the deployment is reachable. Configure GitHub Actions under Automations. Set PROJECT_ID to the destination project and SUITE_NAME to the suite of migrated journeys. The deploy webhook is the other trigger: it queues runs and does not block the deploy. Both need Pro or Team. Source · checked 2026-11-05.
  4. For a journey that has to keep running after January 15, 2027, create a schedule in Automations and select the environment and suite. Use the allowance below to decide whether Free fits. Hourly, every 6 hours and weekly need Pro. After the first green run from the replacement trigger, turn off the TesterArmy schedule for that journey. Source 1 · checked 2026-11-05. Source 2 · checked 2026-11-05.
  5. If the journey should live as TypeScript in the repository, stop here and follow e2e's migrate guide instead. e2e and the hosted TesterArmy product are separate. This playbook does not import a TesterArmy project into either one. Source 1 · checked 2026-11-05. Source 2 · checked 2026-11-05.

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 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 duplicate runs are intentional.

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 e2e or the existing account fits better

Stay on TesterArmy only if you already have an account and you still need the hosted cloud while you finish moving. New sign-ups are closed. The homepage says existing accounts keep working until January 15, 2027. Source · checked 2026-11-05.

Move to e2e when you want TypeScript tests in the repository, mobile targets, or your own model. e2e.com says the products are separate and that TesterArmy does not use e2e underneath. Their migrate guide is the official path. Monito does not test native mobile apps and does not run Firefox or WebKit. Source 1 · checked 2026-11-05. Source 2 · checked 2026-11-05.

The seed post says e2e cloud is launching next year. It does not list a price, and this page does not invent one. Until that cloud exists, e2e runs on your machine or in your CI. Source · checked 2026-11-05.

What to keep outside this migration

Move hosted browser journeys whose expected result you can review. Use e2e's guide when the destination is tests in the repository.

Do not treat a Monito scenario as a copy of an e2e test. The seed post says the hosted platform and e2e are different products, and e2e.com repeats that.

Do not state a price for e2e cloud. The seed post says it is next year and does not publish a price.

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 scenarioAll switching playbooks