Migrate Checkly Agentic Checks

Move Checkly Agentic Checks before December 1, 2026. Map prompts, credentials and schedules to Monito, with examples and a deploy webhook cutover.

Agentic Checks stop running on December 1, 2026. Deactivated checks retain their configuration and history. Source · checked 2026-10-23.

Replace the journeys you still need before December 1, 2026. Start by copying each prompt and recording its settings. Checkly says these checks stop running on that date. It does not say that an active check will be converted automatically, or specify what happens to its history afterward. Do not make the deadline your first test of the replacement. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

Choose the destination by what the check protects. A browser journey can become a Monito scenario with instructions and an expected outcome. If you need a script, an API workflow or several monitoring locations, review Checkly's own replacement before moving anything. The examples here are newly written configurations, with fictional app paths and test data for you to replace. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

What the source documentation says

Checkly recommends a Browser Check for a web journey or a Multistep Check for an API workflow, with automatic repair. Copy the prompt, recreate the check, inspect its script and assertions, match frequency, locations and alerts, save its check intent, enable repair, then deactivate the original. Source · checked 2026-10-23.

In a CLI-managed project, replacing AgenticCheck and deploying deletes the old check and its history. Deactivation preserves them; removing the construct and deploying does not. Source · checked 2026-10-23.

CLI 10 no longer includes AgenticCheck. A project that still defines one fails to load. The CLI 10 release candidate documents the removal. Source · checked 2026-10-23.

Keep CLI 9.x while managing the old Agentic Checks. Source · checked 2026-10-23.

What translates and what changes

Checkly Agentic Checks concepts mapped to Monito
 Checkly Agentic ChecksMonito
PromptThe prompt is the monitoring goal; the agent first discovers a reusable script. Source · checked 2026-10-23.Name the scenario and put the actions in What to test. Add the expected result to that same text.
Success criteriaAgenticCheck has no separate assertions field. Outcomes and guardrails belong in prompt. Source · checked 2026-10-23.State what must be visible or persist after the action, including what must not happen. A success toast alone may be insufficient.
Frequencyfrequency supports intervals down to 5 minutes. Source · checked 2026-10-23.Presets are hourly, every 6 hours, daily and weekly, in UTC. There is no 5-minute schedule. See the current Free allowance below.
Locationslocations selects public Checkly locations. Agentic Checks do not support 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.
Secrets and variables{{VARIABLE_NAME}} references expose account variables and secrets to the prompt. Source · checked 2026-10-23.Store email, password and any TOTP setup key in an environment login. Protected-preview request headers are also stored on the environment. There is no general import of prompt variables.

Replace references with a saved login role and explicit non-secret test data. Keep secret values out of the scenario text.

AlertsalertChannels configures the Checkly alert destinations. Source · checked 2026-10-23.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.
CI triggerThe Agentic Checks guide shows npx checkly test and npx checkly deploy. 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.
Skills and custom stepsagentRuntime.skills installs additional skills on the Checkly runner. Source · checked 2026-10-23.There is no AgenticCheck skill importer. Translate the browser behavior into instructions and outcomes. Keep required custom executable steps in their existing runner.
HistoryA replacement has its own results. Deactivation keeps the old configuration and history; deleting through a deploy removes them. Source · checked 2026-10-23.Your new scenario starts its own run history. Keep the old reports separately; they are not imported into Monito.

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 · ts
import { AgenticCheck, Frequency } from 'checkly/constructs'

new AgenticCheck('account-dashboard', {
  name: 'Account dashboard access',
  prompt: 'Open https://app.example.com/login. Sign in with {{QA_EMAIL}} and {{QA_PASSWORD}}. Open the account dashboard. Pass only when the account menu and recent activity are visible. A sign-in error or a blank dashboard is a failure.',
  frequency: Frequency.EVERY_1H,
  locations: ['us-east-1'],
  tags: ['account-access'],
})

Illustrative AgenticCheck using documented fields. Replace the account-specific values. Source · checked 2026-10-23.

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

Instructions: Sign in using the environment's saved QA login. Open the account dashboard.

Expected: The account menu and recent activity are visible. A sign-in error or a blank dashboard fails the scenario.

Create the QA login on Staging before running this scenario. Select that login in the scenario form. Do not copy the password into What to test. If you need to exercise the sign-in form on every run, select Start logged out under Options, or leave Reuse login sessions off on the login. Session reuse is off by default. A blocked challenge leaves this journey unverified; it does not establish that the dashboard works. To keep this hourly cadence in Monito, choose an hourly schedule on Pro or Team.

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 · ts
import { AgenticCheck, Frequency } from 'checkly/constructs'

new AgenticCheck('checkout-review', {
  name: 'Delivery total at checkout',
  prompt: 'Open https://shop.example.com/catalog. Add the test mug to an empty cart and proceed to checkout using the test shipping details. Stop at review. The selected item and shipping charge must be visible, and their sum must equal the displayed total. Do not place the order.',
  frequency: Frequency.EVERY_1H,
  locations: ['us-east-1'],
  alertChannels: [checkoutAlerts],
  tags: ['checkout'],
})

Illustrative AgenticCheck body. checkoutAlerts stands for your existing alert-channel construct; no destination or credentials are supplied here. Source · checked 2026-10-23.

After · Monito scenario
Name: Delivery total at checkout
Starting path: /catalog
Environment: Staging

Instructions: Start with an empty cart, add the test mug and proceed to checkout using the test shipping details in the scenario. Stop at the review screen without placing the order.

Expected: The review shows the selected item and shipping charge. The displayed total equals their sum.

Replace the test mug and shipping details with a stable staging fixture before saving. Retain the stop-at-review guardrail. The conversion moves the arithmetic requirement into the expected result so that reaching checkout cannot satisfy the whole scenario. To keep this hourly cadence in Monito, choose an hourly schedule on Pro or Team. Do not silently reduce monitoring coverage to fit an allowance.

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 · ts
import { AgenticCheck, Frequency } from 'checkly/constructs'

new AgenticCheck('profile-display-name', {
  name: 'Profile name persists',
  prompt: 'Open https://app.example.com/settings/profile. Sign in with {{QA_EMAIL}} and {{QA_PASSWORD}} if needed. Set the disposable account display name to Migration sample and save. Check the success notice and updated member list, then reload. The saved name must remain.',
  frequency: Frequency.EVERY_1H,
  locations: ['us-east-1'],
  tags: ['settings'],
  agentRuntime: { skills: [] },
})

Illustrative AgenticCheck body. An empty skills list is the documented default; inventory any skills your own check actually needs. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

After · Monito scenario
Name: Profile name persists
Starting path: /settings/profile
Environment: Staging

Instructions: Use the saved QA login for a disposable account. Change its display name 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.

Use an account whose profile you can change. Set its starting display name to a different value before each validation run so the save actually changes something. A successful click and toast do not prove that the server stored the name. Keep the reload in the instructions and require persistence in the expected result. To keep this hourly cadence in Monito, choose an hourly schedule on Pro or Team.

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. Open the Agentic Check and use Copy prompt. Record its frequency, locations, alerts, variable names and custom skills. Keep secret values in your credential store. Record which outcomes catch a real regression and which steps only prepare the test. Source · checked 2026-10-23.
  2. Create the Monito environment with the intended base URL and saved login. Recreate one browser journey, using the mappings above. Run it manually and read the expected outcome against the report. Resolve missing access and test data before adding a trigger.
  3. Create a Smoke suite containing the migrated scenarios and a Staging environment, or change those example names below to your own. Under Automations, open Deploy webhook, obtain the URL and generate the secret. Store them as MONITO_WEBHOOK_URL and MONITO_WEBHOOK_SECRET in the deployment environment.
  4. Replace the npx checkly test step for these migrated journeys with the POST below after a successful deployment. This changes the pipeline to asynchronous checks. Keep a blocking workflow if a failing browser journey must prevent the pipeline from succeeding. Keep Checkly commands for checks you are retaining there. Source · checked 2026-10-23.
  5. For recurring coverage, create a schedule in Automations and select the environment and suite. Choose Hourly on Pro or Team to match these examples. If daily coverage is enough, choose Daily with a UTC hour and use the allowance below to decide whether Free fits. Failure emails go to your account's email address; turn them on or off under Settings, Run alerts. Connect Slack channels on Team.
  6. After validating the replacement, deactivate the original before December 1, 2026 if you want to retain its history. Do not then remove AgenticCheck from a CLI-managed project and deploy expecting that history to survive. Checkly says the deploy deletes it. Keep CLI 9.x while the project still defines AgenticCheck; CLI 10 fails to load it. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23. Source 3 · checked 2026-10-23. Source 4 · checked 2026-10-23.
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.

Deactivation is a deliberate cutover step. Checkly's guide tells you to retain the original for its configuration and history or remove it later. It does not promise indefinite retention, or describe what becomes of checks left active at the cutoff. Preserve the reports you need before deleting any definition. Source · checked 2026-10-23.

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 Checkly's own replacement fits better

Stay with Checkly's migration path if you want a generated script you can inspect and repair there. Their guide recreates browser journeys as Browser Checks and API workflows as Multistep Checks. Inspect the generated assertions, save the check intent and enable automatic repair. Match the old frequency, locations and alerts before deactivating the Agentic Check. Source · checked 2026-10-23.

Use that path when several public locations, a five-minute cadence or the existing alert setup are requirements. Monito offers a single us-east region and an hourly minimum schedule. It does not replace the wider monitoring account. Checkly's guide explicitly asks you to match those settings on its replacement; verify them before you cut over. Source 1 · checked 2026-10-23. Source 2 · checked 2026-10-23.

Inventory behavior supplied by custom skills before moving. If the check depends on executable setup you cannot express and verify as browser actions, keep that work in a runner that supports it. If your journey also needs an email inbox supplied by the testing vendor, Monito does not provide one. Its disposable inbox login requires your own Resend receiving domain and account. Source · checked 2026-10-23.

What to keep outside this migration

Move browser journeys whose instructions and expected results you can review. Keep API monitors, unit tests and isolated component tests in their existing tools.

Do not treat a changed schedule or a single region as equivalent coverage. Record the difference with the person responsible for responding to a failure.

Do not move archived run history into scenario instructions. Keep it as an independent record and use new reports to validate the replacement.

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