Follow new updates and improvements to Checkly.

May 31st 2024


Due to an infrastructure migration, we've updated our static IP ranges. All our customers have already been informed about this change via a set of three emails sent out of the last three weeks.

Here is a short recap:

What changed?

  • We've shortened the list of IPv4s per region. The current list of static IPv4s is a subset of the previous list.

  • The IPv6 range is unchanged.

Where do I find the new IP ranges?

The new ranges can be fetched from our public API, for instance:


Please reference our docs on static IP ranges and allowlisting for more info.

What do I need to do?

  • If you do not use IP based allowlisting in your infrastructure with Checkly, no action is needed.

  • If you do use IP based allowlisting, your current firewall(s) will still correctly allow Checkly traffic as the new range is a subset of the old range. However, once we release the superfluous IPv4s back to our hosting provider, these IPv4s could be reused by others and potentially form a threat to you.

Static IP ranges are available to all users on all Checkly plans.

Questions? Reach out to or Join our Slack community

Type @ to mention posts

May 29th 2024


The Checkly OpenTelemetry (OTel) Tracing integration is now in public beta. With this integration you can correlate your synthetic checks with backend traces, cut through the noise and find out the root cause of a slow or failing check 10x faster than before.

  • Slow TTFB? We can point you to any slow database queries or high latency third party services.

  • Got a 500 error? We can show you where it went wrong in your application stack.

Check out the short Loom video below to get a quick demo ๐Ÿ‘‡

In a nutshell, it works as follows:

  1. All HTTP requests made by your checks are automatically instrumented with W3C traceparent and tracestate headers.

  2. Ingest traces into Checkly from your OTel setup and display them in the Checkly UI, allowing you to correlate check results with backend traces.

  3. Send every check run to your 3rd party OTel backend as a span, enabling you to correlate check runs and their metadata like check run location, check name etc. with other telemetry data.

Head over to the dedicated OpenTelemetry section in the app to get started.

Check our docs for more information.

This feature is available for free on all plans during the beta.

Questions or feedback? Join our Slack community.

Type @ to mention posts

April 23rd 2024


Together with our friends over at we just released the Checkly x integration. This integrations enables you to:

  1. Directly fire and resolve alerts in when a check fails.

  2. Get a direct link to the Checkly check result.

  3. Connect your alerts into broader on-call and other workflows.

Getting started is quick and easy. Just head over to your account, go to Alerts > Sources, select Checkly and follow the instructions. We also have full docs over here on how to get started.

This feature is available on the Team and Enterprise plans.

If you have questions or feedback, join our Slack community and share your thoughts with Checkly users from across the globe.

Type @ to mention posts

April 17th 2024


We just shipped our new Coralogix integration. With this integration you can:

  • Send all of your checks as Open Telemetry traces to your Coralogix account.

  • Automatically correlate the HTTP requests executed by your checks to your backend.

  • Get a link in all check results pointing to a trace in Coralogix ๐Ÿ‘‡ making detection and triaging times 10x shorter when a check fails.

For more details, check out the documentation or hop right in and navigate to the integrations page.

This feature is available on the Team and Enterprise plans.

If you have questions or feedback, join our Slack community and share your thoughts with Checkly users from across the globe.

Type @ to mention posts

April 10th 2024


We are excited to announce that Multistep checks are now in General Availability.

Increase reliability and confidence in your API user flows by chaining together multiple requests in a single check.

What is a Multistep Check?

Like Checklyโ€™s Browser checks, a Multistep check is a fully programmable Playwright test script at its core. It uses Playwright's API testing framework to mimic real user journeys and actions. The flexible nature of the check allows you to change, delete, or add new data in between requests, simulating any user action.

Unlike traditional multistep monitoring, you are not limited to a form builder; you can create a check that monitors exactly what you need.

Of course, Multistep checks support Checklyโ€™s monitoring-as-code workflow, not limiting you to working in our in-app editor. Work from your preferred IDE, and use our CLI to automatically update your monitors as part of your CI/CD process.

Creating your first Multistep check

To get started, simply log in to Checkly and click the โ€˜+โ€™ button in the left-hand sidebar. Select โ€˜Multistep checkโ€™ from the options and either choose a template that fits your use case, or start from scratch.

Multistep checks use Playwrights test.step method to build the check result tree. We recommend only using a single request per step in your test, and use descriptive labels for each step to make debugging and analyzing failed check runs easier. Hereโ€™s a short example.

import { test, expect } from '@playwright/test'

const baseUrl = ''

test('My test', async ({request}) => {
    await test.step('First step', async () => {
        const health = await request.get(`${baseUrl}/health`)

    await test.step('Second step', async () => {
        const response = await`${baseUrl}/health`)
        // Assertions for the second step

You can test-run the script directly from the check editor to confirm it is working as intended. The left-hand sidebar contains the check results from your ad-hoc runs for easy debugging.

Multistep checks are supported on the Checkly runtime 2023.09 or later.

Degraded state and soft assertions

If you want to monitor your API for non-critical errors or performance degradations you can use the degraded check state. This allows you to signal that parts of a multistep check performed slower than expected, or that it triggered assertions that are of lower criticality.

To trigger a degraded state multistep checks use a helper library,ย @checkly/playwright-helpers, which is included in runtimeย 2023.09ย and later. The helper library contains two methods,ย markCheckAsDegradedย andย getAPIResponseTime.

Here is an example of how to use the degraded state in a check together with soft assertions from Playwright to signal that something is not performing as expected, without interrupting the execution of the check.

import { test, expect } from '@playwright/test'
import { getAPIResponseTime, markCheckAsDegraded } from "@checkly/playwright-helpers"

const baseUrl = ''

test('My test', async ({request}) => {
    await test.step('First step', async () => {
        const health = await request.get(`${baseUrl}/health`)
        //Check if the request status is degraded
        expect.soft(getAPIResponseTime(health), 'GET /health is too  slow').toBeLessThanOrEqual(200)

  // Trigger degraded state if check failed due to soft assertion
  if ( {
    markCheckAsDegraded('Check degraded due to soft assertion failure.')

@checkly/playwright-helpers is also available for use in browser checks.

Multistep checks and monitoring as code

Multistep checks are fully supported in the Checkly monitoring as code workflow. You can use either the Checkly CLI or our Terraform provider. Here is an example of how to use the MultistepCheck construct.

import { MultiStepCheck } from 'checkly/constructs'

new MultiStepCheck('multistep-check-1', {
  name: 'Multistep Check #1',
  runtimeId: '2024.02',
  frequency: Frequency.EVERY_10M,
  locations: ['us-east-1', 'eu-west-1'],
  code: {
    entrypoint: path.join(__dirname, 'home.spec.ts')

Availability and price

Multistep checks are available on all current Checkly price plans. Each request in a multistep check counts as a single API check run for billing purposes.

Additional resources

If you have questions or feedback, join our Slack community and share your thoughts with Checkly users from across the globe.

Happy monitoring!

Type @ to mention posts

April 3rd 2024


We are happy to announce that we have released a major update to our check overview page. It is now easier than ever to:

  • Understand the historical health of your check at a glance.

  • Find specific check results.

The new check overview chart comes with a side panel where all check results from the selected time period are visible. This allows for fast deep dives into check reports to understand and resolve incidents.

Below is an example of how navigating the old overview page could be like. Finding a result that happened in the past could be challenging, so making this a smooth experience was important to us.

With the new chart, finding a check result is simple. Each bar on the chart represents a time range and shows the aggregate of all check runs that happened in that time, with color coding to allow for fast identification of failing runs. You can use the filters on the top of the overview page to select the overall time range, and filter on locations.

Selecting a bar in the new chart further filters out the results in the sidebar, allowing you to quickly navigate to any given check result. You can also filter on the status in the chart legend to exclude a status from the results.

If you have questions or feedback, join our Slack community and share your thoughts with Checkly users from across the globe.

Happy monitoring!

Type @ to mention posts

March 26th 2024


Our latest runtime, 2024.02, is now GA.

The 2024.02 runtime includes several new libraries, plus updates to Playwright and other libraries. We also removed support for Mocha.

New libraries:

  • @axe-core/playwright

  • @opentelemetry/api

  • @opentelemetry/sdk-metrics

  • @opentelemetry/exporter-metrics-otlp-grpc

  • chai-json-schema

  • nice-grpc

  • pdftojson

We have also enabled the node datagram and performance modules.

With the addition of @axe-core/playwright, accessibility monitoring is now possible. Here is an introduction video on how to work with Axe and Playwright ๐Ÿ‘‡

2024.02 uses Playwright 1.42.1. For a list of all library versions, see our runtime specs documentation.

The private location agent supporting 2024.02 is v3.3.0. Pull the latest version from

If you have questions or feedback, join our Slack community and let us know.

Type @ to mention posts

February 14th 2024



This patch release of the Checkly CLI fixes some small bugs and adds

Alerting additions

You can now set the alerting threshold for failing locations when using parallel scheduling. in the Web UI this configured like below ๐Ÿ‘‡

For the CLI, you add the parallelRunFailureTreshold object to your alertEscalationPolicy:

alertEscalationPolicy: AlertEscalationBuilder
      { amount: 2, interval: 5 }, // sets reminders
      { enabled: true, percentage: 50 } // sets the parallelRunFailureThreshold

Global configuration fix

We missed exporting the userAgent as an option for global configuration. This option is added now. This means two things:

1. You can set a user agent in your global config, e.g.

use: {
  userAgent: 'my funky user'

2. Using the devices macro now sets the correct user agent header. That field was ignored earlier, e.g.

import { devices } from '@playwright/test'

use: {
   ...devices['iPhone 12 Pro Max landscape']

the above code will set the user agent header to:

"Mozilla/5.0 (iPhone; CPU iPhone OS 14_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1"

Learn more about the Playwright Global Configuration Beta.

To get started with the Checkly CLI just run

npm create checkly 

Or upgrade your existing installation with

npm install checkly@latest

Check the full release note on GitHub here

Type @ to mention posts

January 31st 2024


Parallel scheduling is now GA.

Reduce mean time to detection, get better insights when addressing outages, and get improved data granularity on all performance trends with parallel scheduling.

A check using parallel scheduling will run from each configured location each time it is scheduled, ensuring that any local outages are detected instantly. Alerts are sent as soon as a location is registered as failing or degrading, minimizing the time from failure to your team being notified.

Changing your scheduling method

With GA, parallel scheduling is now the default for all new checks and groups. To change the scheduling method, go to "Scheduling & Locations" when editing your check.

Parallel scheduling is fully supported in our monitoring as code workflow. With our CLI, just add the runParallel property to your construct:

import { ApiCheck, AssertionBuilder } from 'checkly/constructs'

new ApiCheck('hello-api-1', {
  name: 'Hello API',
  runParallel: true,
  locations: ['eu-central-1', 'us-east-1'],
  request: {
    method: 'GET',
    url: '',
    assertions: [

Similar, with Terraform just add run_parallel

resource "checkly_check" "list-all-checks" {
  name                      = "List all checks"
  type                      = "API"
  frequency                 = 0
  frequency_offset          = 10
  activated                 = false
  muted                     = false
  run_parallel              = true
  locations                 = ["eu-north-1", "eu-central-1", "us-west-1", "ap-northeast-1"]
  degraded_response_time    = 5000
  max_response_time         = 20000
  request {
    method                    = "GET"
    url                       = ""

Viewing check results

The check overview page will now show the progress of all locations as a check is running, giving you instant feedback if a certain location is taking longer than usual.

The check result page has been updated to support results from multiple locations. You can switch between locations in the sidebar when viewing the check result page.

Quickly compare the results from multiple locations, reviewing failures, Playwright traces or screenshots to understand how your service behaves globally.

Pricing and availability

  • Parallel check scheduling is available on all current plans: Hobby, Team, and Enterprise. Deprecated plan types are not supported.

  • Each location selected for a check running in parallel does a full check run per execution. An API check that runs in five locations will be billed for five check runs per execution. For more information on pricing, see our documentation: Check pricing.

Additional resources

Type @ to mention posts

January 26th 2024


We now support a subset of global configuration options for our Playwright-powered Browser and Multistep checks via our CLI.

To get started, upgrade your CLI to version 4.6.0 and add any supported options to the new playwrightConfig section in your checkly.config.ts file. To quickly copy the supported settings over to your checkly.config.ts file, you can run...

npx checkly sync-playwright

You should now have a checkly.config.ts file similar to the example below ๐Ÿ‘‡

import { defineConfig } from 'checkly'
import { devices } from '@playwright/test'

const config = defineConfig({
  projectName: 'Checkly website',
  logicalId: 'checkly-website-project',
  checks: {
    locations: ['us-east-1', 'eu-west-1'],
    playwrightConfig: {
      timeout: 30000,
      use: {
        baseURL: '',      
        ...devices['iPhone 12 Pro Max landscape'],
        extraHTTPHeaders: {
          'x-my-custom-header': 'value',        
    checkMatch: ['**/__checks__/**/*.check.ts'],
    browserChecks: {
      testMatch: ['**/__checks__/**/*.spec.ts'],

export default config

Note that we now set the timeout, baseUrl, device properties and extraHTTPHeaders globally for all Browser and Multistep checks using the canonical Playwright configuration options. You can now write a Browser check like...

import { test, expect } from '@playwright/test'

test('Checkly pricing page', async ({ page, baseURL }) => {
  const response = await page.goto(baseURL! + '/pricing')

After deploying your checks with npx checkly deploy, you can access the fully rendered configuration in the new "playwright test config"-section in the web UI editor.

This is our first step to fully support all global configuration options. We still have some dragons to slay to support globalSetup, globalTeardown, storageState and dependencies but we are working it!

Check our docs for more information.

Type @ to mention posts