Changelog

We just released a new version of the Checkly CLI that supports test session retries.

You can specify the number of retries between 0 and 3 that you’d like Checkly to attempt when running npx checkly test or npx checkly trigger.

For example:

npx checkly test --retries=2 

You can also specify the default amount of retries on your Checkly configuration file:

cli: {
    retries: 2,
}

All retry attempts will be visible in your command line as they’re happening:

1 retrying, 5 passed, 6 total

And on the web interface at Checkly:

Learn more about using the Checkly CLI commands here.

To get started with the Checkly CLI, run:

npm create checkly 

Or upgrade to the latest Checkly CLI version with:

npm install checkly@latest

Check the full release note on GitHub here

Questions or feedback? Join our Slack community.

Connect your backend OpenTelemetry traces to Checkly. See all your traces’ health at the new Traces page and get immediate insight into why your check failed.

Make sure to drill down to investigate further.

Check our docs here to get started.

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

Happy monitoring!

Checkly now supports multi-factor authentication using one-time passwords.

Users on a team or enterprise plan can secure their accounts by enabling MFA in the user settings.

Once enabled, on your next login you will be asked to set up a one-time password app. Checkly supports Google Authenticator, Microsoft Authenticator, Authy, or Auth0 Guardian.

Administrators can view which users have enabled MFA in the Members list in the account settings.

Multi-factor authentication is available today on all paid plans.

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

Happy monitoring!

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.

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.

• Instrumenting your code with OpenTelemetry SDKs

• Sending traces to Checkly using the OpenTelemetry collector

• Exporting traces to 3rd party services

Questions or feedback? Join our Slack community.

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.

• Instrumenting your code with OpenTelemetry SDKs

• Sending traces to Checkly using the OpenTelemetry collector

• Exporting traces to 3rd party services

Questions or feedback? Join our Slack community.

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

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.

• Instrumenting your code with OpenTelemetry SDKs

• Sending traces to Checkly using the OpenTelemetry collector

• Exporting traces to 3rd party services

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

Questions or feedback? Join our Slack community.