We’re excited to introduce “Read & Run”, a new role designed for anyone who needs to execute tests or trigger checks without having the ability to deploy or modify configuration.

What this role can do

Users with “Read & Run” can:

• Read: View all resources in the account.

• Run: Manually invoke checks and tests across all supported interfaces, including:

  • Running npx checkly test, trigger, or pw-test via the CLI.

  • Triggering a new check session via the API.

  • Running checks ad hoc in the UI (e.g. “Schedule now”).

What users with “Read & Run” can't do: deploy changes or modify checks, environment variables, or any other configuration.

The role sits between “Read” and “Read & Write”, letting users run tests safely while keeping configuration protected from unintended modifications. Check our documentation on Team Member Roles for an overview.

Common use cases

“Read & Run” enables safe troubleshooting without write privileges. This can come in handy during incident response, for example, when engineers need to re-run a test session or check to validate a fix, without risking accidental configuration changes.

When assigned to a service user, it’s also a good fit for CI/CD pipelines that need to run tests but shouldn’t be able to deploy or modify resources.

Ready to try it out? You can set it up directly from your member settings.

Happy monitoring!

Questions or feedback? Join our Slack community.

We’re expanding access to Checkly status pages to all plans.

Status pages help communicate to your customers about the status of your services, letting them consult and subscribe to incident updates.

How status pages work

Status pages are organized with cards listing services which provide an overview of the uptime of your system in the past 90 days. Your customers can see at a glance if any incident happened and quickly access its details.

Remain proactive using incident automation

You can connect checks with services to automatically declare incidents when those fail, and resolve the incident when the check recovers. This helps keeping your customers in the loop as timely as possible.

Updated pricing to match your needs

We originally limited Status Pages to enterprise customers but quickly realized that was against our mission to help customers communicate the state of their systems more broadly. We thus decided to open Status Pages to everyone and revisit our pricing to align with our mission to help our customers Detect, Communicate and Resolve issues as fast as possible.

Our free plan includes 1 status page, 20 services and up to 250 subscribers to keep your early adopters informed about incidents through email notifications.

For paid plans, we now provide the flexibility to choose a “Communicate” add-on to get the volume of Status Pages your company needs:

1. “Communicate Starter”: comes with more services and subscribers, as well as custom domains to offer a more branded experience

2. “Communicate Team”: goes even further with additional pages, services and subscribers, theme customization, and more

White-labeling and removing the reference to Checkly remains an Enterprise-only option.

Check out our pricing page for more details

Happy monitoring!

Questions or feedback? Join our Slack community.

Here’s a roundup of the new features and improvements we shipped over the past month.

DNS monitors are here!

We’re excited to share that DNS monitors are now available on all plans.

DNS monitors help you track DNS resolution and lookup times, so you can spot misconfigurations, expired records, or resolver latency issues before your customers notice.

Learn more:

• Check out the change log update.

• Jump into the developer docs.

• Or try it out right away!

Error Groups for Test Sessions

You can now find all errors that happened during Test Sessions in the new “Error Groups” tab. Error Groups for Test Sessions work the same way as Error Groups for scheduled checks and monitors, but add dimensions for "project" and "environment" properties, populated by the Checkly CLI.

• This feature is now live for all users on all plans at no extra charge.

• Test Session Error Groups are in early development; expect updates in the coming days and weeks.

• If you are running the Checkly Agent on Private Locations, make sure you’re on version 6.1.5 or later. Check how to upgrade here.

Checkly and Playwright

Our latest flagship checks, Playwright Check Suites, now come with new features. Additionally, there's a new Playwright Reporter, which you can enable by adding it to your playwright.config.ts and running npx playwright test.

Playwright Check Suites

• There’s a new graph on the Check Overview page for your Playwright Check Suite. It gives you a clear breakdown of individual test case statuses.

  

• Terraform support for Playwright Check Suites starting in version v1.17.0.

• Private Locations now support playwright test performance, availability metrics and graphs. Starting on v6.1.5.

• Support for a new CHECKLY environment variable that lets you define specific behaviour when running scheduled Playwright Check Suites. Check the documentation here.

  • By default, when running npx checkly test, npx checkly trigger or npx checkly pw-test, the variable CI=1 is set, since you’re running your tests.

  • When using scheduled checks, CI will be unset since they’re running against production.

  • To use custom test retries, traces or workers values when running your Playwright Check Suite on a schedule, you can now use the variable CHECKLY in your playwright.config.ts, which is set to 1 for scheduled Checkly runs. Use

    CHECKLY_RUN_SOURCE for advanced configuration that depends on all the different Checkly run types.

Playwright Reporter (Beta)

Checkly’s Playwright Reporter is here to make it easier to keep track of your Playwright tests wherever they run: locally, in CI/CD, or as monitors in Playwright Check Suites. It’s still early, we’ve built it to bring more clarity to your test suite:

• Central view of all Playwright test runs across environments.

• Clearer insight into flaky, slow, and failing tests.

• Helpful debugging assets (videos, traces, snapshots).

Developer Experience

• Checkly import is now live in the UI: The old code snippets shown in the “export to code” modal have been removed and replaced with CLI import instructions. This makes it easy to pull UI-created resources into your codebase, where they can be fully version-controlled and automated through CI/CD. Learn more in our guide on Monitoring as Code.

Fixes

• Check tags in PagerDuty alert payloads: Tags from a failing check are now included in the payload sent to PagerDuty.

• API docs cleanup: We’ve fixed various inconsistencies (e.g. authorization header info) and added missing examples (e.g. on retrieving account IDs). Further restructuring is planned to improve clarity. If you spot other issues in the API docs, please let us know.

• Rate limit visibility: API responses now include rate-limit headers, helping you monitor and manage your API usage.

• Enhanced dark mode: Date picker, error states, and input fields now render more clearly in dark mode.

Got feedback? We’d love to hear from you!

You can share your feedback on our feedback hub or connect via the Checkly community Slack.

Happy monitoring!

We updated Checkly AI (currently in beta) with new features based on user feedback in the last period. Here are the highlights:

AI Analysis for Error Groups

You can now trigger an AI analysis for any Browser Check or Playwright Check Suites check right from an Error Group. This works in the context of Test Sessions and regular Monitoring.

User Provided Context

You can now tweak the User Impact and Root Cause by providing your own context after the initial analysis is done and run the analysis again. Providing this context has many use cases:

• Ignoring errors that are expected or irrelevant.

• Pointing out specific errors that you know are critical.

• Adding knowledge about UX / UI patterns.

This is a first release. We will make user provided context a first class citizen in the future so you can document the quirks of your service and get relevant analyses out of the box.

Miscellaneous

• We now recognize graphQL errors correctly and provide them to our AI analysis.

• We now recognize various types of chunk loading errors correctly.

• We’ve move to a streaming, async solution to AI analysis in our web app is more performant and reliable.

Checkly AI is by default enabled for all users, except for Enterprise customers. If you’re an Enterprise customer, go to the Labs section and turn on “Checkly AI.” Then, opt in to the feature on the “AI” screen in account settings.

We’re introducing a new Playwright Reporter, in Beta, built to give you the clarity and focus your test suite deserves, especially if you’re running it in CI/CD and accessing the right assets from GitHub Actions can be tricky.

Get vanilla Playwright results displayed in Checkly, with quick access to all assets, including videos, traces, snapshots, and screenshots.

And the best part? You get all your Playwright test results in one place. Whether they come from local runs, CI/CD, monitors or checkly pw-test; finally giving you full visibility over how your suite behaves over time.

Whether you’re running a massive suite in a monorepo or just trying to figure out why your login test is failing again, this reporter is built to get you answers fast.

Available today in Beta. And yes, the Playwright Reporter is completely free while in Beta.

It’s literally npx playwright test, but with :checkly-logo-light-mode: Checkly eyes:

• Quickly spot error groups within your suite.

• Identify slow tests.

• Quickly access assets.

• Navigate your projects as a tree view or flat view.

• Easily click through as many traces and assets as you need!

• See local runs, CI runs, checkly pw-test ones, and monitor runs together, side-by-side.

Configuring the Playwright Reporter

1. In your playwright.config.* file, include the npm package with the checkly reporter as part of your reporters, make sure to also use json and list, ensuring that json comes before @checkly/playwright-reporter

   import { defineConfig } from "@playwright/test"; export default defineConfig({ reporter: [ ["list"], ["json", { outputFile: "test-results/playwright-test-report.json" }], ["@checkly/playwright-reporter"], ], }); 

2. Log in to Checkly, get your account ID and generate an API key from your settings

3. Export them as environment variables in your shell

   export CHECKLY_API_KEY=cu_123.... export CHECKLY_ACCOUNT_ID=b2f... 

4. Run Playwright test as you normally would and you’ll get a link to the result in Checkly where you can quickly access assets, traces videos and more.

   npx playwright test # ... **🔗 Test session URL: <https://chkly.link/l/>...** 

Read the docs on the Playwright Reporter to learn more.

Happy testing!

Known beta limitations

We’re shipping this in Beta so you can break it, shape it, and help us tune it. And of course, use it for free while we iterate.

We’ve scoped these for later iterations, and we’re truly curious about your thoughts and how important you consider them.

• Proactive secret scrubbing in the UI → In Playwright Check Suites and pw-test runs, executions go through our cloud, and Checkly scrubs declared or suspected secrets; in contrast, the reporter directly zips and uploads all data to be displayed, as is.

• Metrics across test suite runs → In Playwright Check Suites, you can see per-test performance and availability over time, and this is not yet available in the Reporter.

Questions or feedback? Join our Slack community.

You can also create an issue or talk with our support team.

We’re excited to announce DNS monitors in Checkly, now available on all plans.

DNS monitors let you track the resolution and lookup times of your DNS records, helping you catch misconfigurations, expired records, and resolver latency issues before your customers do.

➡️ Create your first DNS monitor (and prove that it's not always DNS)

🔎 Common Use Cases

DNS monitors are useful for:

• Detecting when a domain stops resolving to its IP address to prevent downtime.

• Verifying records against a specific DNS server (e.g. 1.1.1.1 for Cloudflare) to catch resolver-specific issues.

• Monitoring DNS response times to spot slow or inconsistent resolution.

• Tracking latency issues across different regions.

🚀 Get Started with DNS Monitors

Jump into your dashboard to add a new DNS monitor.

DNS monitors are also fully integrated into Checkly’s Monitoring as Code (MaC) workflows and available in:

• CLI (v6.9.0+): DnsMonitor

• Terraform (v1.16.0+): checkly_dns_monitor

• Pulumi (v2.7.0+): checkly.DnsMonitor

To get started:

1. Configure the domain and record type you want to check.

2. Optionally override the default DNS server (8.8.8.8).

3. Define assertions on response time, return codes, or specific string matches in the DNS response.

import { Frequency, DnsAssertionBuilder, DnsMonitor } from "checkly/constructs"

new DnsMonitor("dns-monitor", {
  name: "DNS A Record Monitor",
  activated: true,
  frequency: Frequency.EVERY_5M,
  locations: ["us-east-1", "eu-central-1"],
  maxResponseTime: 800,
  degradedResponseTime: 400,
  tags: ["dns", "production", "critical"],
  request: {
    query: "checklyhq.com",
    recordType: "A",
    nameServer: "9.9.9.9",
    port: 53,
    assertions: [
      DnsAssertionBuilder.textAnswer().contains("3.162.103.33")
    ],
  },
})

👉 Learn more about available configuration options in our developer docs on DNS monitoring.

💬 Connect with Us

Give DNS monitors a try and let us know what you think! We’d love to hear your feedback - drop a comment below or join the conversation in the Checkly community Slack.

Happy monitoring!

** Running on a schedule, from 20+ locations!

We’re thrilled to announce that Playwright Check Suites are now Generally Available (GA). Bringing full Playwright test suite support to your monitoring workflows, with a native developer experience and new visibility into cross-browser, cross-project test execution.

The feature request with most upvotes in Checkly’s history? 📬 Shipped. And we went way beyond it.

Create your first Playwright Check Suite today.

It’s a major milestone in uniting E2E testing and active monitoring for teams like yours.

💡 What’s new in Playwright Check Suites?

📁 Full playwright.config.ts or (.js) support

(This is how E2E and monitoring finally get on the same page)

Check Suites now respect global Playwright config files — giving you full control over:

• Viewport sizes

• Global setup/teardown

• storageState

• Screenshot, trace, video toggles…

🧠 Native Playwright test execution

No wrappers. No rewrites. Just run your existing Playwright tests as scheduled checks. Support includes:

• Projects (great for browser, env, and auth separation)

• Multi-browser (Chromium, Firefox, WebKit)

• Mobile device emulations (hi you, iphone-12, we’ve seen you often during the beta phase!)

• Private/public npm dependencies

• Feature-rich tests with setup hooks, fake devices, media access, and network mocking

• Use a custom testCommand to make each Check suite, completely yours.

📊 Granular test metrics in Check Overview

The check overview now shows per-test and region execution duration and flaky test insights. Duration graphs filter down based on your selected views for a clean, consistent UX.

🔎 Detailed results views

The new check result page shows exactly where failures happened — across browsers, projects, or both — with inline links to:

• The line of code that failed

• Traces, videos, screenshots, and snapshots associated.

• Logs scoped to the failed test only

• Slow tests

📁 Flat project view

A new, test-centric overview lets you browse tests across all projects in a single flat list, improving discoverability and reducing navigation friction.

🚀 Optimized for real-world Playwright setups

We support large test files, multi-file suites, custom test organization, Playwright tags (e.g. @smoke, @auth-only), and test reuse across teams and environments.

📈 Performance comparisons across projects

You can compare test performance per browser per project — and yes, it looks like Firefox is winning in speed for our docs site now hosted with Mintlify, who knew. 👀

🧩 In a gist

With Playwright Check Suites, you can now:

• Reuse your existing Playwright test suites 1:1 as production-grade, scheduled checks.

• Adopt monitoring faster — no need to split dev/test/monitoring logic.

• Run the same tests across multiple environments, browsers, and teams with full alerting control.

• Debug and iterate faster with rich execution insights and direct links to failure points.

This is the monitoring experience we wished existed when building complex frontend apps with confidence.

⚙️ What’s next?

Local Playwright test reporter

Debug your checks locally with the same fidelity you get in the cloud, using the same sharp view we have on Playwright Check Suite results!

Thanks to everyone who requested and upvoted this (👋 @Younes Jallouli )— the feedback helped shape what Check Suites became.

Ready to try it?

Head over to your Checkly dashboard and create your first Playwright Check Suite — or reach out opening a support chat, if you want early access to the reporter!

Happy monitoring!

Questions or feedback? Join our Slack community!

We’ve been busy shipping! Here’s a roundup of the new features and improvements we introduced over the last month.

Fresh Check Overview with Error Groups

We redesigned the check overview page to get you to what matters, faster. This update also introduces a new feature: Error Groups. While still in beta, they already make it much easier to see which errors occurred over time, how often, and in which locations.

Next to Error Groups, we added the following tweaks and updates:

• Quicker and clearer filters for date, status and retries. Shave off three clicks to get to that annoying randomly failing check.

• A distilled and easier-to-scan list of alerts and possible alert notifications.

• An updated locations list to scan performance by location.

…plus dozens of small quality-of-life improvements that make this page smoother and snappier to use.

TCP Dumps & Traceroute Reports

API checks now support TCP dumps and traceroute reports to help debug network-level issues. On checks that fail due to network errors, you’ll now see:

• TCP Dumps: Capture raw packet data and download it as a .pcap file (e.g. for Wireshark). Great for starting an investigation in case of an error, such as incomplete TCP/TLS handshakes or delayed packets.

• Traceroute reports: Trace the full path your request takes across the internet, including latency and packet loss at each hop. Pinpoint where packets drop or latency spikes.

👉 Learn more in the docs.

We’d love your feedback: should these tools be available in other check types? Are there other debugging features you’d like us to add? Drop in a comment below or ping us in the community Slack 🙂

Meet pw-test: Playwright tests, now in Checkly ✨

As part of Playwright Check Suites, we’ve launched a brand new pw-test command that supports both Checkly and Playwright flags. The npx checkly pw-test command runs Playwright tests with Checkly monitoring features, and reuses the Playwright CLI arguments. This command automatically records test sessions without requiring the --record flag.

npx checkly pw-test {checkly flags} -- {playwright flags}

npx checkly pw-test -- --project="firefox"

npx checkly pw-test --create-check -- --project="firefox"

Test and create Playwright Check Suites from your local repository using pw-test. Learn more in our docs.

👩‍💻 Developer Experience

• Check session trigger API: You can now programmatically run checks on demand, equivalent to clicking Schedule now in the UI.

  • POST /v1/check-sessions/trigger – Start an ad-hoc session for all activated checks matching the provided filters

  • GET /v1/check-sessions/{checkSessionId} – Retrieve the status and results of a running or completed session

  • GET /v1/check-sessions/{checkSessionId}/completion – Wait for a session to finish and return final results

  Learn more in our API docs.

• Single retries: A new SINGLE_RETRY strategy has been added for simple use cases such as Uptime Monitors. Learn more.

• Network retries: After announcing network retries as a UI feature a few weeks back, they are now available in the CLI, Terraform, and Pulumi providers. Learn more.

• New IP ranges: We’ve increased the list of IP addresses we use to run checks. The API endpoints are already updated with the new IPs, but if you manually manage an allowlist of Checkly IP ranges, make sure to include the new ones. We will begin migrating to the new IP addresses on October 15th.

  → us-east-1 (N. Virginia) new IP ranges:

  • 173.208.3.141

  • 209.50.250.200

  • 209.50.250.199

  • 2607:f5b7:1:135:5::/112

  • 2607:f5b7:3:e:1::/112

  • 2607:f5b7:3:e:2::/112

  → us-west-1 (California) new IP ranges:

  • 23.19.66.246

  • 23.19.45.129

  • 23.19.66.245

  • 2607:f5b4:1:12:d::/112

  • 2607:f5b4:1:12:c::/112

  • 2607:f5b4:1:1c:2::/112

  → eu-west-2 (London) new IP ranges:

  • 23.19.59.129

  • 23.106.239.101

  • 23.106.239.174

  • 2a0d:3003:b666:a00a:2::/112

  • 2a0d:3003:b666:a006:12::/112

  • 2a0d:3003:b666:a005:7::/112

🐛 Fixes:

• Alert Escalation Reminders: Escalation reminders now respect the alert channel set at the check level. Previously, reminders could be sent via a group’s channel even when group-level overrides were disabled.

Got feedback? We’d love to hear from you!

You can share your feedback on our feedback hub or connect via the Checkly community Slack.

Happy monitoring!