Changelog

AI agents can now connect directly to Checkly through the Model Context Protocol (MCP).

The new Checkly MCP Server gives your agentic client of choice a secure, OAuth-based access to your Checkly account, so your agent can inspect live monitoring data, understand check health, investigate recent failures, and help with incident workflows without leaving your conversation.

With the Checkly MCP Server, your agent can:

• List accounts and understand available Checkly features

• Inspect check status, recent results, test sessions, and result assets

• Read and trigger Rocky AI root cause analyses

• Trigger existing deployed checks on demand

• Read status pages and manage status page incidents

• Manage account-level environment variables, with secret values protected

This is designed for live Checkly account operations. For creating, editing, testing, or deploying Monitoring as Code projects, keep using Checkly Skills and the Checkly CLI. The MCP server runs remotely, so it cannot access your local project files.

You can connect Codex, Claude Code, Cursor, VS Code, or any MCP client that supports Streamable HTTP and OAuth.

Learn how to connect your client in the MCP Server docs:
https://checklyhq.com/docs/ai/mcp-server

Happy monitoring!

Questions or feedback? Join our Slack community.

We shipped a focused batch of Playwright Check Suite improvements to make runs faster, more reliable, customizable and easier to debug.

You can now cancel runs, use custom Node / Bun versions, rely on automatic retries for transient dependency failures, cache Playwright browsers in Private Locations and use globalTimeout from Playwright and see trace-processing details.

Playwright Check Suite runs are now cancellable.

Started a Playwright Check Suite run and already know it needs to stop?

You can now cancel queued or in-progress runs from the UI or CLI. This works for runs started from Schedule now and for runs triggered through test sessions, including:

• npx checkly test

• npx checkly pw-test

• npx checkly trigger

You can cancel a run in two ways:

• Click Cancel Run from the Playwright Check Suite Runs or Test Session Run pages

• Press CTRL+C on Checkly CLI 8.0.0 and later

Cancelled runs now show a Cancelled status in your run history so you can distinguish them from failures.

Choose your Node/Bun runtime engine

Playwright Check Suites now support multiple Node.js and Bun engines, configurable from the UI and

in code.

Starting with Checkly CLI 8.1.0, the CLI looks at your project’s version files and selects a compatible runtime automatically, including:

• .nvmrc

• .node-version

• .bun-version

Supported runtimes:

• Node.js 22 default

• Node.js 24

• Node.js 26

• Bun 1.3 default

If your project specifies a different version, Checkly picks the closest compatible runtime for you.

You can also override automatic detection by setting the engine property:

import { Engine, PlaywrightCheck } from 'checkly/constructs' new PlaywrightCheck('my-playwright-check', { /* ... */ engine: Engine.node('24'), }) 

Available from Checkly CLI 8.1.0

Browser caching across runs in Private Locations

Playwright Browser caching has now landed in Private Locations: Playwright Check Suites now cache Playwright browsers across runs on the same Private Location agent. No more re-downloading browsers on every run: when a cached browser exists, the installation step is skipped entirely.

• Faster startup times

• No repeated browser downloads

• Lower bandwidth usage on Private Location agents

• Zero configuration required

Caching is scoped to each Private Location agent. Runs on different agents install browsers independently. Available since Private Location agent version 8.2.0.

Playwright’s globalTimeout is now fully supported

Playwright's globalTimeout now behaves as you expect in Checkly.

Until now, global timeouts set in your Playwright configuration were respected at runtime but not visible in Check run results. That's fixed.

You can control the maximum duration of a Check Suite run using Playwright's native global timeout (in milliseconds). In your playwright.config.ts:

export default defineConfig({ globalTimeout: 120_000, // 2 minutes }); 

Or pass it as a flag in your testCommand:

testCommand: npx playwright test --global-timeout=120000

When a run exceeds the limit, Playwright skips all remaining tests and reports the check as failed. The timeout error appears in both the logs and the Failures tab, along with a troubleshooting guide to help you identify what to adjust.

A few things to keep in mind:

• If you set a global timeout in both playwright.config.ts and your testCommand, the flag takes precedence, matching Playwright’s own behaviour.

• globalTimeout limits the entire suite, not individual tests. For per-test limits, use Playwright's timeout option.

Automatic retries for environment setup steps

Some setup steps fail for boring reasons: a temporary network issue, a cache hiccup, or the internet having a little wobble.

Check runs now automatically retry setup steps that are prone to transient failures, reducing false negatives without requiring any config changes.

• Downloaded package managers are cached in the dependency cache after a successful Corepack run

• If all dependency cache download attempts fail, the run falls back to a clean install

• No configuration needed. Retries happen automatically.

More reliability, better logs

We’ve added a couple of behind-the-scenes upgrades that make Playwright Check Suites more reliable and easier to troubleshoot.

• Dependencies cache has moved to a Least Recently Used cache, all current Playwright Check Suites and new ones will now use and automatically refresh the same cache key so that it doesn’t expire.

• Trace processing details in logs. Check logs now surface post-processing details: report generation, trace processing, and trace sanitizing (secret scrubbing), each with its own timing. This gives you a clearer view of what happens after your tests finish, especially for suites with lots of traces.

Happy monitoring!

Questions or feedback? Join our Slack community.

Checkly CLI 8 is here with three big behavior changes: the CLI is now ESM-only, CTRL+C now cancels running checks, and test, pw-test and trigger now record results by default.

It also adds support for multiple Node.js/Bun versions, simplifies TypeScript support, updates how Playwright include patterns resolve, and automatically loads .env files when present.

v8.0.0 ESM-only and updated Node.js requirements

The Checkly CLI is now distributed as ESM only instead of CommonJS.

CLI 8 requires Node.js versions matching ^20.19.0 || >=22.12.0

In plain English, you’ll need to use

• Node.js 20.19.0 or later on the Node 20 release line

• Node.js 22.12.0 or later

Earlier Node.js 20 and 22 versions are not supported. Before upgrading, make sure your local development, CI, and deployment environments use a compatible Node.js version.

Your own projects can of course still use CommonJS.

v8.1.0 Playwright Check Suites now support multiple Node/Bun versions

When using Playwright Check Suites, the CLI now looks at your project’s version files (.nvmrc, .node-version, .bun-version, etc.) and selects a compatible Node or Bun version for you. We currently support the following versions:

• Node.js: 22 (default), 24, 26

• Bun: 1.3 (default)

If you use a different version, we’ll choose the most compatible version for you.

You can also override automatic detection by setting the new engine property:

import { Engine, PlaywrightCheck } from 'checkly/constructs'

new PlaywrightCheck('my-playwright-check', {
  /* ... */
  engine: Engine.node('24'),
})

v8.0.0 No need to install a TypeScript loader separately anymore!

Starting with CLI 8, Checkly uses jiti exclusively. It supports modern TypeScript features out of the box, does not require a tsconfig, and now supports tsconfig paths automatically.

jiti is now bundled as a direct dependency when you install Checkly:

npm install checkly@latest 

So you no longer need to install or manage it separately. That means no extra loader setup and one fewer dependency to manage.

For type checking, please rely on your editor of choice, and make sure that your type checking workflows cover your Checkly files. jiti does not produce type errors.

ts-node is no longer supported.

v8.0.0 Test sessions are now recorded by default

The test and trigger commands now record results by default.

That means your runs will be recorded unless you explicitly opt out. To disable recording, use the --no-record option:

npx checkly test --no-record
npx checkly trigger --no-record

If your scripts relied on recording being off by default, update them before upgrading.

v8.0.0 CTRL+C now cancels running Playwright Check Suites

Ever started checkly test or checkly trigger and realized three seconds later it was absolutely not going to pass?

No need to watch it fail in slow motion.

Pressing CTRL+C during test , pw-test or trigger now cancels in-flight test sessions instead of leaving them running in the background eating into your quota.

npx checkly test 
# CTRL+C 
# Cancelling Playwright checks... ⊘ Docs Environment (0ms)

Need the previous “keep running in the cloud after I disconnect” behaviour? Run in detached mode with --detach or -d

npx checkly test --detach 
# CTRL+C 
# Checks will continue running in the cloud. 

v8.0.0 .env files are now loaded automatically

The CLI now automatically loads a .env file when one is present.

You can use it for configuration such as:

• API keys

• Account IDs

• Environment-specific variables

To disable automatic .env loading entirely, set:

CHECKLY_NO_DOTENV=1 

v8.0.0 Playwright include patterns now resolve from the config directory

Playwright check Suites include patterns now resolve relative to the directory of your Playwright config file, not the project root.

This now matches Playwright’s own behavior, which should make path resolution more predictable.

If your Playwright config lives in a subdirectory, double-check your include globs after upgrading.

Extra!

checkly rca run now support --test-session-error-group or -te to trigger a Root Cause Analysis on Test Session Error Groups.

Happy monitoring (and testing!)

Questions or feedback? Join our Slack community.