Migrate Ghost Inspector tests to Monito

Move Ghost Inspector recordings to Monito scenarios. Map selectors, logins and schedules, review benchmark runs and replace the CI trigger.

Ghost Inspector's Chrome and Firefox recorder records actions and assertions. Source · checked 2026-10-23.

Start with a recorded journey whose selectors you keep repairing. Read the actions and assertions in the editor, then describe what the user is trying to do and what must be true afterward. Keep the original recording while you validate the replacement. Changing how you identify a button must not remove the assertion that made the check useful. Source · checked 2026-10-23.

Our team wrote the step lists below as illustrative recordings. They are not Ghost Inspector JSON or Selenium exports. Replace the paths, selectors and test data with your own. The linked benchmark runs show comparable login, checkout and profile behavior; they do not establish that your recording has moved successfully.

What the source documentation says

The codeless editor targets elements using CSS or XPath and supports JavaScript steps. Source · checked 2026-10-23.

Tests support interval schedules, with an Advanced Schedule for specific days and times on paid plans. Tests and suites can also run through the API. Source · checked 2026-10-23.

Exports include re-importable Ghost Inspector JSON, Selenium IDE v3 .side and Selenium IDE v1 .html. Suites download as a .zip. Source · checked 2026-10-23.

Ghost Inspector's Visual Capture setting enables or disables screenshots and video during a test run. Source · checked 2026-10-23.

Starter includes 10,000 test runs per month. Tests pause for the rest of the period when the monthly run limit is exceeded. Source · checked 2026-10-23.

What translates and what changes

Ghost Inspector concepts mapped to Monito
	Ghost Inspector	Monito
Recorded steps and CSS/XPath targets	The codeless editor targets elements using CSS or XPath and supports JavaScript steps. Source 1 · checked 2026-10-23. Source 2 · 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. Use the recording to recover intent. Monito does not import Ghost Inspector JSON or execute its JavaScript steps.
Assertions	Read each recorded assertion separately from the actions that precede it. 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 steps	Inventory the credentials and variable values your login steps use. Record which account and initial state each journey needs.	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 start URL and any --startUrl override supplied by CI. Source · checked 2026-10-23.	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 intervals	Tests support interval schedules, with an Advanced Schedule for specific days and times on paid plans. Tests and suites can also run through the API. Source · 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 if you need that cadence. Use Daily only when daily coverage is sufficient; it is not an equivalent replacement for a shorter interval.
CI action or API trigger	The GitHub Actions example uses docker://ghostinspector/cli with test execute or suite execute, --apiKey, --startUrl and --errorOnFail. 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.
Alerts	List the recipients and destinations that currently receive failures for the recordings 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.
Private locations	Check whether these journeys depend on access to an internal app or a particular runner location.	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.
Run evidence	Keep the reports and video your team currently relies on for debugging these journeys. Source · checked 2026-10-23.	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.
Suite execution	Identify the journeys selected by suite execute and any shared test accounts. 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.

Replace recorded sign-in targets with a login outcome

Before · text

Start URL: https://app.example.com/login
Preparation: supply the disposable QA account's email and password.
Type the email into CSS input[name="email"].
Type the password into CSS input[name="password"].
Click XPath //button[normalize-space()="Sign in"].
Assert that the account menu is visible.
Assert that Recent activity is visible on the dashboard.
Assert that no sign-in error is visible.

Illustrative recorded step list using CSS and XPath targets. This is not an export file. 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.

A run of a comparable journey from our benchmark

Keep the checkout assertion when removing selectors

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 CSS [data-product="test-mug"] button.add-to-cart.
Click the Checkout link.
Choose the saved staging shipping address.
Click XPath //button[normalize-space()="Review order"].
Assert that the order contains Test mug and a shipping charge.
Assert that the displayed total equals the item amount plus shipping.
Stop at review; do not place the order.

Illustrative recorded step list, not Ghost Inspector JSON. The arithmetic line states the required outcome; it does not invent a Ghost Inspector assertion field. 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.

Preserve the arithmetic requirement even if the recording previously implemented it in JavaScript. The scenario checks displayed amounts; it does not execute that script. Compare the original requirement with what is visible at review. Prepare or reset the cart before validation and give checkout its own account so another suite member 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.

Keep the reload check in a profile recording

Before · text

Start URL: https://app.example.com/settings/profile
Preparation: sign in with the disposable profile account.
Confirm its display name is different from Migration sample.
Replace CSS input[name="displayName"] with Migration sample.
Click XPath //button[normalize-space()="Save"].
Assert that the success notice appears and the member list updates.
Reload the page.
Assert that the display name is still Migration sample.

Illustrative recorded step list. Reset the account's display name before each run. These selectors describe a fictional app, not an exported customer recording. 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.

The Save click and success notice are only part of this recording. Keep the final assertion after reload. Reset the display name before subsequent runs so saving changes something. A saved login provides access; it does not reset profile data or preserve the recorded test's setup script. Keep that setup in your own workflow.

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 recordings, assertions, JavaScript steps, start URLs and schedule settings. Keep the original definitions and reports. Use the documented exports for reference if useful, but do not treat a Selenium export as a Monito import file. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.
Create the Monito environment and saved logins, then a suite for the moved checks. Write each journey's actions and expected outcome. Prepare independent accounts and data. Run the old recordings and new scenarios against the same build and investigate any disagreement, including cannot-verify results.
Replace the docker://ghostinspector/cli step using test execute or suite execute 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 Ghost Inspector steps for retained recordings. Source · checked 2026-10-23.
Create the replacement schedule in Automations with the intended environment and suite. Choose Daily with a UTC hour only if daily coverage meets the requirement; otherwise use an available preset that does. Check run-alert emails and connect Slack on Team where needed. After the first green Monito run from the replacement trigger, inspect its evidence and turn off the old schedules for the moved checks. 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 Ghost Inspector fits better

Stay on Ghost Inspector when Selenium export is part of your handoff or your team needs to retain executable JavaScript steps. Its documented exports include Selenium IDE formats and re-importable Ghost Inspector JSON. Monito does not export executable test code. A scenario conversion cannot preserve a script whose behavior you have not translated into a browser outcome. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

Keep your current workflow if video for signed-in journeys is a requirement. Recording is off for signed-in Monito runs; masked screenshots are captured instead. Review the actual evidence your team needs before retiring the old reports. A green verdict does not establish that the replacement gives you the same debugging artifacts. Source · checked 2026-10-23.

Stay put when high run volume within your existing allowance matters more than changing authoring. Ghost Inspector Starter includes 10,000 test runs per month, and tests pause after the monthly limit is exceeded. Compare your actual scheduled workload with Monito's current allowance before moving it. A Standard run costs 1 credit and an Advanced run costs 10 credits. Source · checked 2026-10-23.

What to keep outside this migration

Move browser journeys with observable outcomes. Keep JavaScript setup, API checks and any Selenium export workflow that the team still requires in the existing tool.

Keep Ghost Inspector if the evidence and run-volume tradeoffs above rule out a move. Monito's hourly minimum and single us-east region are coverage constraints to review before switching schedules.

Monito has no private-location worker. Keep checks that need an internal runner in a tool that can reach their target. An environment base URL does not supply private network access.

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