Migrate Datadog browser tests to Monito

Convert Datadog Synthetic browser recordings to Monito scenarios. Map schedules and CI, and scope status pages against monitoring requirements.

Datadog Synthetic browser tests record steps with the Datadog Record Test extension in Chrome or Edge. Source · checked 2026-10-23.

Choose the recorded browser journeys whose selectors you keep fixing. Read the steps and assertions before writing a scenario, including any User Specified Locator added to repair a target. Preserve what the check must prove. Moving a checkout journey does not mean moving the monitoring account that helps your team diagnose an incident. Source · checked 2026-10-23.

Decide the monitoring scope before cutover. A public Monito status page can show whether selected browser journeys work, with their verification times. If your team links these tests to APM traces, monitors or dashboards in Datadog, keep them there. Our team uses illustrative step lists below, with comparable public benchmark runs for review.

What the source documentation says

A User Specified Locator can supply a CSS or XPath selector when the recorder targets the wrong element. Source · checked 2026-10-23.

Browser test intervals range from every one minute to once per week, with managed or private locations. Source · checked 2026-10-23.

CI can run browser tests with datadog-ci synthetics run-tests from @datadog/datadog-ci, or through the API. Source · checked 2026-10-23.

Bits Testing accepts a plain-language description of coverage and generates regular Synthetic tests, which run every 5 minutes by default. Source · checked 2026-10-23.

What translates and what changes

Datadog Synthetics concepts mapped to Monito
	Datadog Synthetics	Monito
Recorded steps and CSS/XPath targets	A User Specified Locator can supply a CSS or XPath selector when the recorder targets the wrong element. Source · 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. Rewrite the purpose of a repaired locator. There is no Datadog browser-test configuration importer.
Assertions	Read the expected result of each recorded step, including checks after navigation or 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 steps	Inventory the values used during login and the account state required by later steps. Separate credentials from non-secret test data.	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 browser test's start URL and any different target used for deployment checks.	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	Browser test intervals range from every one minute to once per week, with managed or private locations. 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. There is no 1-minute browser schedule. Keep Datadog when that interval is a requirement; hourly checks do not preserve it.
CI action or API trigger	The documented GitHub Action is DataDog/synthetics-ci-github-action@v4.1.1. 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	Record who receives failures for the selected browser tests and which existing alert workflows must remain.	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	Browser tests can run from managed or private locations. Source · checked 2026-10-23.	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. Keep tests that require a private location in Datadog. Do not change the target's network exposure to complete a recording conversion.
Monitors and dashboards	If your team links these tests to APM traces, monitors or dashboards in Datadog, keep them there.	Status pages need the Pro plan. A journey works only when all of its tests pass. Only scheduled and deploy-webhook runs count. Runs you start while editing a test, CI runs against previews and repeat or fix-verification commands never change the page. Missing access or Monito errors leave a gap, not a public failure. Visitors see journey states and verification times, not test instructions or run evidence. A status page reports selected user journeys. Keep any incident-response workflow your team relies on alongside those tests.
Suite execution	Record the browser tests selected by the existing CI command and the data they share. 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.

Convert the sign-in recording without dropping assertions

Before · text

Start URL: https://app.example.com/login
Preparation: supply the disposable QA account's email and password.
Type the email into the Email field.
Type the password into the Password field.
Click Sign in; the repaired User Specified Locator is CSS button[type="submit"].
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 Datadog recorded step list with a User Specified Locator. This is not API JSON or Terraform HCL. The example account has no 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.

Save the account as an environment login instead of pasting credentials into What to test. 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 actual flow uses an authenticator, save its setup key and include that challenge in the scenario. The benchmark below did not complete sign-in.

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

Carry the checkout total into the expected outcome

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 select the saved staging shipping address.
Click Review order; use XPath //button[normalize-space()="Review order"] if needed.
Assert that Test mug appears in the review.
Assert that the shipping charge appears.
Assert that the total equals the item amount plus shipping.
Stop at review without placing an order.

Illustrative recorded step list. The assertions express the intended visible result, not an undocumented Datadog configuration shape. 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.

Keep the total calculation and stop-at-review instruction. Successful navigation to checkout is insufficient. Reset the account's cart before validation and use independent data for concurrent journeys. If this check will support a public status-page journey, validate it on the environment that page reports on and add a schedule there. A preview CI pass does not update that page.

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.

Preserve the profile assertion after reload

Before · text

Start URL: https://app.example.com/settings/profile
Preparation: sign in with a disposable profile account whose name is not Migration sample.
Set Display name to Migration sample.
Click Save; the User Specified Locator is CSS button[data-action="save-profile"].
Assert that the success notice appears.
Assert that the member list shows Migration sample.
Reload the page.
Assert that Display name still contains Migration sample.

Illustrative recorded step list with a repaired CSS target. Reset the display name before each run. No Terraform or API export fields are implied. 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.

Copy the final persistence assertion even if most maintenance has concerned the Save button's locator. A toast can appear before the application has stored the change. Keep the account reset in your existing setup, and compare both reports against the state after reload. Replacing the recording does not replace any incident investigation that follows a confirmed failure.

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

Select the browser tests to move and inventory their intervals, locations, login prerequisites and assertions. Retain checks that require 1-minute intervals or private locations. Record which monitor, dashboard and APM workflows your team will continue using independently of this migration. Source · checked 2026-10-23.
Create a Monito environment, saved logins and a suite for the moved journeys. Run each scenario manually against the same build as the recorded test. Compare outcomes and investigate errors before replacing a trigger. Keep separate accounts for concurrent mutations such as checkout and profile edits.
Replace datadog-ci synthetics run-tests or DataDog/synthetics-ci-github-action@v4.1.1 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 Datadog CI selection for tests you retain there. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.
Create the replacement schedule with the intended environment and suite. Check email 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. Do not disable unrelated monitors or alerts as part of that change.
If you need a public status page, open Status page in the project, choose its environment and map tests to public journey names. Make sure a schedule covers those tests on that environment, then preview and publish when you are ready. Only scheduled and deploy-webhook runs count; the CI checks above do not update the public page. A failure is re-checked before it goes public, and a test must pass once before it can fail publicly. Keep security-sensitive journeys off the public page. 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 Datadog fits better

Stay on Datadog when 1-minute intervals or private locations are requirements. Monito offers a single us-east region and an hourly minimum schedule. It has no private-location worker. A longer interval or a different network path changes what a check can detect, even when the browser actions look the same. Source · checked 2026-10-23.

If your team links these tests to APM traces, monitors or dashboards in Datadog, keep them there. A Monito status page reports the state of selected browser journeys to visitors. Move a journey only if that result meets the reason you run it.

Review Bits Testing before deciding that a new vendor is necessary solely to change authoring. It accepts a plain-language coverage description and generates regular Synthetic tests. Compare the resulting checks with your existing assertions, intervals and location requirements before choosing either migration path. Source · checked 2026-10-23.

What to keep outside this migration

Move selected recorded browser journeys. If your team links these tests to APM traces, monitors or dashboards in Datadog, keep them there.

Stay on Datadog for 1-minute intervals and private locations. Monito status pages do not turn hourly browser scenarios into equivalent monitoring coverage.

A public status page needs scheduled or deploy-webhook evidence on its chosen environment. Manual and preview CI results do not establish its public state. Missing access and Monito errors leave gaps rather than public failures.

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