Migrate Octomind tests to Monito

Rebuild Octomind journeys from saved exports or notes. Map prompts, login variables, TOTP and CI to Monito, with worked scenarios and clear limits.

Octomind's farewell letter set product shutdown for the end of May 2026 and company closure for the end of June 2026. The letter offered to "help you export what you need and wind things down cleanly". Source · checked 2026-10-23.

Start with what you still have. Octomind's product turned off at the end of May 2026; its company closed by the end of June. A fresh export is no longer a migration prerequisite you can rely on. Find your .octomind directory, persisted Playwright files, prompts, screenshots or test notes before deciding which journeys to recreate. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23. Source 3 · checked 2026-10-23.

A prompted Octomind test started as a prompt expanded into intent, instructions and expected outcome. The generated steps were stored in an intermediate representation; Playwright was generated before execution. Recover the purpose and observable result from the material you retained. A Monito scenario needs the actions and expected result, plus a starting path and environment. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

What the source documentation says

octomind pull wrote test cases as YAML into .octomind/. The export commands depended on Octomind's API. With the hosted product shut down, work from files you already exported or your own notes. Source · checked 2026-10-23.

The CLI documented octomind code for generated test code and octomind debug --persist for Playwright files. These commands called the API; this guide does not assume a fresh export is available. Source · checked 2026-10-23.

Dev-mode YAML lived in .octomind/. Documented fields include id, description, prompt, type, entryPointUrlPath, runStatus and elements, with selectors inside the step representation. Source · checked 2026-10-23.

What translates and what changes

Octomind concepts mapped to Monito
 OctomindMonito
Intent and instructionsThe agent expanded a prompt into intent, instructions and expected outcome before generating steps. Source · checked 2026-10-23.Use the intent to name the scenario. Put the actions and expected outcome together in What to test. Select the environment and starting path separately.
Steps and assertionsSaved steps were an intermediate representation used to generate Playwright. Source · checked 2026-10-23.Rewrite the browser behavior as scenario text. There is no Octomind YAML or Playwright suite importer.
Login variables$OCTO_USERNAME and $OCTO_PASSWORD referenced environment credentials. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.Create an environment login with email and password. Select the login role in the scenario. Placeholder names are not substituted automatically.
Authenticator codes$OCTO_TOTP used an authenticator initialization key; Octomind documented TOTP and HOTP. Source · checked 2026-10-23.Save the authenticator setup key in the login's Advanced settings. Monito generates TOTP when signing in. HOTP is not supported.
Email inbox$OCTO_EMAIL supplied a hosted inbox for magic links and email codes. Source · checked 2026-10-23.No vendor-supplied inbox. A disposable test inbox login connects your own Resend account and receiving domain, with an expected sender and subject prefix. It supports codes and magic links for new disposable addresses, not an existing fixed-email account.
Custom variablesEnvironment variables and extracted dynamic variables supplied test data. Source · checked 2026-10-23.Put non-secret fixture values in the instructions. Save logins and protected-preview request headers on the environment. There is no general $OCTO_* variable import or substitution.
Frequency and alertsDaily, weekly and bi-weekly schedules could send failure email. Source · checked 2026-10-23.Use hourly, every 6 hours, daily or weekly schedules in UTC. There is no bi-weekly preset. Failed automated runs can email Free, Pro and Team accounts with run-alert emails enabled; Slack requires Team.
LocationsInspect your retained environment notes for any location requirement.Runs execute in us-east with no region selector or multi-region execution. Moving the URL into an environment does not change that.
CI triggerThe GitHub Action used a URL, API token and testTargetId. A separate GitHub App posted PR comments. Source · checked 2026-10-23.Create a new deploy webhook or blocking GitHub Actions integration on Pro or Team. An Octomind token or testTargetId has no meaning in Monito.
Dependencies and historyLogin could run as a test dependency. Existing exports are the material available after shutdown. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23. Source 3 · checked 2026-10-23.Set up authentication for each scenario through an environment login. Recreate other prerequisites explicitly. New scenarios have their own history; old reports remain separate files.

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.

Recover a sign-in journey

Before · yaml
description: Account dashboard access
entryPointUrlPath: /login
prompt: >-
  Sign in with $OCTO_USERNAME and $OCTO_PASSWORD.
  Complete the authenticator challenge with $OCTO_TOTP.
  Open the account dashboard. The account menu and recent
  activity must be visible; a sign-in error is a failure.

Shape of an octomind pull export (illustrative). Excerpt using documented keys, not a complete runnable export. The prompt is newly written. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23. Source 3 · checked 2026-10-23.

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

Instructions: Sign in with the saved QA login and complete its authenticator challenge. Open the account dashboard.

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

Move the email, password and authenticator setup key into the environment login before saving the scenario. Do not paste a current rotating code into the instructions. 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 retained notes only identify a username, recover the test account's access before interpreting any dashboard result.

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.

Recover checkout intent from steps

Before · yaml
description: Checkout review includes delivery
entryPointUrlPath: /catalog
prompt: >-
  Add the test mug to an empty cart. Enter the staging
  shipping details and open checkout review. The item and
  shipping charge must appear, and the total must equal
  their sum. Stop before placing the order.

Shape of an octomind pull export (illustrative). Only description, entryPointUrlPath and prompt are shown. No undocumented step or selector shape is implied. Source · checked 2026-10-23.

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

Instructions: Add the test mug to an empty cart. Enter the staging shipping details supplied in the scenario and open checkout review without submitting an order.

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

If your export contains only recorded steps, read them to identify the business assertion. Clicking Continue is preparation; checking the final total is the outcome. Replace the product and shipping placeholders with repeatable staging data. Keep the instruction to stop before payment so recreating the journey does not expand what the original check was meant to do.

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.

Recover a settings persistence check

Before · yaml
description: Display name survives reload
entryPointUrlPath: /settings/profile
prompt: >-
  Use the disposable QA account. Change its display name
  to Migration sample and save. Confirm the success notice
  and changed member list. Reload and confirm that the
  saved name is still Migration sample.

Shape of an octomind pull export (illustrative). The documented prompt field carries the intended outcome. This is not a recovered customer file. 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 QA account's saved login. Change its display name to Migration sample, save, inspect the member list and reload.

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

Recover the initial account state as well as the click sequence. Start with a different display name so saving is a real mutation. A dependency that prepared this account needs an explicit replacement in your test setup. Do not weaken the expectation to a toast just because the export makes that assertion easier to recognize.

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. Inventory existing files and notes. Look for .octomind YAML and any Playwright files saved through code export or debug --persist. Those export commands depended on the API. With the product shut down, do not spend the cutover trying to recover an export from an unavailable service. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23. Source 3 · checked 2026-10-23.
  2. Choose which journeys to recreate and which exported scripts to keep. For each migrated journey, write the intent, actions and expected result in your own words. Record the entry path, login, starting data and any dependency that used to prepare it. Keep the retained files for review. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.
  3. Create the target environment and saved login in Monito. Re-enter the authenticator setup key where needed. Provision your own Resend test inbox if the inbox was used to sign up or sign in with a new address. An inbox step later in the journey needs another tool. A missing inbox is a missing prerequisite, not an assertion to delete. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.
  4. Save and run each scenario manually. Read the report against the original expected result. Inspect persistence after reload for settings and the actual total for checkout. Establish that the target account and data let the journey run before connecting CI.
  5. Create a Smoke suite and Staging environment, or replace those names below. Under Automations, create a deploy webhook. Store its URL and secret in your deployment environment. Replace the old Octomind Action for the migrated journeys with the POST after successful deployment. It queues checks in the background; use the blocking GitHub workflow below if CI must wait. Source · checked 2026-10-23.
  6. Add a Daily schedule with a UTC hour for recurring coverage. The current Free allowance is below. Select the intended environment and suite, then check the run-alert email preference. Connect Slack on Team if that is where you respond to failures. Disable old trigger configuration once you have verified the new path.
After deployment · shell
curl --fail-with-body -X POST "$MONITO_WEBHOOK_URL" \
  -H "Authorization: Bearer $MONITO_WEBHOOK_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"env":"Staging","suite":"Smoke"}'

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

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

Keep the exported files and notes after the cutover. They may contain assertions or prerequisite steps that did not fit the first browser journey you recreated. A new green report validates only its own scenario. It does not establish that the old suite's coverage has been reproduced.

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 keeping your exported tests fits better

If you already have complete Playwright files, inspect them before rewriting their intent. Octomind documented persisting the Playwright configuration and files for subsequent Playwright runs. Keeping those files may be the better choice when your team wants to review executable assertions and maintain the suite itself. This option depends on having the files already, not on the old export API becoming available. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

A prompt conversion does not preserve a dependency chain automatically. Octomind could chain a login test before another test. Recreate the required account and state explicitly in the destination. Keep the flow in another tool if you cannot reproduce its prerequisites or need the exact generated script as the artifact your team reviews. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

Keep an email-dependent flow elsewhere if you need a vendor-provided inbox or cannot configure a dedicated Resend receiving domain. Octomind supplied that inbox. Monito's disposable inbox option requires your account and cannot read an existing fixed-email account's mailbox. HOTP has no Monito equivalent; bi-weekly schedules become weekly or daily. Do not erase these requirements to complete the migration. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23. Source 3 · checked 2026-10-23.

What to keep outside this migration

Move browser journeys with recoverable intent and an observable result. Keep unit, component and API tests in their existing tools.

Keep exported executable tests when ownership of those files is part of the requirement. Monito does not import an Octomind project or return a maintained Playwright suite.

Do not claim the migration is complete while a required login, inbox or setup dependency is missing. Record those gaps alongside the scenarios you have verified.

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