Changelog

Follow new updates and improvements to Checkly.

June 25th 2024

Improved

Now everyone can define if their API checks are going to be executed either using IPv4 or IPv6. That setting is available through the Checkly app, the CLI and our Terraform provider.

To get started head to the Checkly UI, and find the IP family selector in the API check editor.

If you are using the CLI use the property ipFamily with the value IPv4 or IPv6.

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

new ApiCheck('hello-api-1', {
  name: 'Hello API',
  activated: true,
  request: {
    method: 'GET',
    ipFamily: 'IPv6'
    url: 'https://mac-demo-repo.vercel.app/api/hello',
    assertions: [
      AssertionBuilder.statusCode().equals(200)
    ],
  }
})

If you are using Terraform, use the setting ip_family with value IPv4 or IPv6.

resource "checkly_check" "hello-api-1" {
  name                      = "Hello API"
  type                      = "API"
  activated                 = true
  frequency                 = 1

  locations = [
    "us-west-1",
    "eu-central-1"
  ]

  request {
    url              = "https://mac-demo-repo.vercel.app/api/hello"
    follow_redirects = true
    skip_ssl         = false
    ip_family        = "IPv6"
    assertion {
      source     = "STATUS_CODE"
      comparison = "EQUALS"
      target     = "200"
    }
  }
}

Questions or feedback? Join our Slack community.

June 25th 2024

New

You can now view events in your OpenTelemetry (OTel) traces. Events are structured logs you can add to any span inside your trace to give extra context about work being done during the lifetime of a span. Each event has a name, a timestamp and optionally extra attributes in a typical key/value pair style.

For instance, events are commonly used to record exceptions and their stack traces that happen within the bounds of a span. The OpenTelemetry documentation has examples for all popular languages on how to add events to spans.

OpenTelemetry tracing on Checkly is currently in beta. Head over to the dedicated OpenTelemetry section in the app to get started.

Check our docs for more information.

Questions or feedback? Join our Slack community.


June 24th 2024

Improved

We just added gRPC support to our OpenTelemetry (OTel) ingestion endpoints. This means you can now send OTel traces using the default settings in the OTel collector, Go language and other SDKs that default to gRPC instead of HTTP/proto.

As per OTel conventions, the gRPC endpoint is hosted on port 4317.

Here's an example of sending traces to Checkly with the OTel collector using the default gRPC protocol.

receivers:
  otlp:
    protocols:
      http:
      grpc:
processors:
  batch:
  filter/checkly:
    traces:
      span:
        # remove all spans that the trace state doesn't have an object
        # which key is "checkly" and value is "true"
        - 'trace_state["checkly"] != "true"'
exporters:
  otlp/checkly:
    endpoint: "otel.eu-west-1.checklyhq.com:4317"
    headers:
      authorization: "${env:CHECKLY_OTEL_API_KEY}"
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [filter/checkly, batch]
      exporters: [otlp/checkly]

OpenTelemetry tracing on Checkly is currently in beta. Head over to the dedicated OpenTelemetry section in the app to get started.

Check our docs for more information.

Questions or feedback? Join our Slack community.

May 31st 2024

Improved

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:

curl https://api.checklyhq.com/v1/static-ips

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 support@checklyhq.com or Join our Slack community

May 29th 2024

New

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.

April 23rd 2024

New

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

  1. Directly fire and resolve alerts in incident.io 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 incident.io 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.

April 17th 2024

New

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.

April 10th 2024

New

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 = 'https://api.myproduct.com/v1'

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

    await test.step('Second step', async () => {
        const response = await request.post(`${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 = 'https://api.myproduct.com/v1'

test('My test', async ({request}) => {
    await test.step('First step', async () => {
        const health = await request.get(`${baseUrl}/health`)
        expect(health).toBeOK()
        
        //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 (test.info().errors.length) {
    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!

April 3rd 2024

Improved

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!

March 26th 2024

New

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 https://hub.docker.com/r/checkly/agent

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