We are very excited to announce the beta release of Multistep API checks!

Now, you can test and monitor entire user flows by chaining together multiple API requests or test all methods on an endpoint in a single check, all using our web script editor or your IDE of choice.

Why Multistep API checks?

As a fully programmable check type, multistep API checks allow you to mimic real user journeys and actions closely. Change, delete, or add new data between request steps as needed. Unlike traditional multistep solutions, you are not bound to what some form builder allows; it is all done in code you control.

Multistep API checks support the entire Checkly monitoring-as-code workflow from day one; you can integrate existing Playwright API checks today and use our CLI or Terraform provider to run them on Checkly.

Multistep API checks and Browser Checks

While similar to Checkly’s browser checks, multistep API checks provide deep insights into each API request made with a purpose-built result viewer. Multistep checks are also much more affordable, with each request priced at the price of an API check. This allows you to monitor complex user journeys reliably and economically.

Getting started

Similar to browser checks, we use Playwright to power multistep API checks. When creating your first multistep API check, you can choose from one of the existing templates to get started, and if you have existing Playwright API tests, you can now use those to monitor your product.

To provide clear and actionable information, multistep checks rely on the test.step method. When writing a multistep check, we recommend having a test step with a descriptive label for each request required and any assertions related to the request inside the same test step. Here is a simple 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 expect(response).toBeOK()
    });

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

When building a new multistep check using our web editor, you can use the test result information in the side panel to view error information, request results, and assertion details. Simply click on any request node to get the full result.

The request result and assertion details are also available in the check result view:

Multistep checks support all Checkly alerting channels, including custom webhooks. The new check type also supports test sessions, dashboards, maintenance windows, and more.

Using the Checkly CLI or Terraform

This first release of multistep API checks includes full support for the Checkly CLI and our Terraform provider, allowing you to include multistep checks in your MaC workflow from day one. The MultistepCheck construct is available in Checkly CLI v4.3.0

import { MultiStepCheck } from 'checkly/constructs'

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

Additional resources

• Multistep API checks documentation

• CLI documentation

• Terraform provider documentation

• Playwright API testing

• If you have requests for guides or additional starting templates, join our Slack community and let us know.

We look forward to hearing what you think of the latest addition to Checkly!

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

If you are using one of our SSO integrations, it might be hard or even impossible to create "service users" to call the Checkly public API or use our CLI from a background process like CI. This is because API keys are tied to users.

To make life easier here, we just introduced Service API keys. Service API keys work very similar to user API keys, but are different on some parts.

• Service API keys can have access roles: READ_ONLY, READ_WRITE and ADMIN.

• Service API keys are tied to one account only. They are not usable for cross account access.

• Service API keys can only be used for public API access and CLI usage, just like user API keys. Just set the API in your terminal or script, or export it as CHECKLY_API_KEY=sv_...

curl -H "X-Checkly-Account: 438481ea-0eab-43d6-8932-redacted" -H "Authorization: Bearer sv_9afd2cc24a46432bba922-redacted" https://api.checklyhq.com/v1/checks

Check out the full docs right here.

This feature is available on Enterprise plans only.

Questions or feedback? Join our Slack community.

We just released V2 of our Prometheus exporter. This new version brings extra gauges, counters and histograms so you can get more accurate Checkly data in your preferred Prometheus setup and dashboarding tool.

New metric types

Three of highlights our new metric types are:

• The checkly_browser_check_web_vitals_seconds histogram, which allows you to get a breakdown of your web vitals for a browser checks.

• The checkly_api_check_timing_seconds histogram, which breaks down the timing phases of your API Check, e.g. DNS time, TTFB etc.

• The checkly_time_to_ssl_expiry_seconds gauge, which tracks when your SSL certificate will expire in seconds.

PromQL example

We also added some PromQL examples to show case how you might use these new metrics. For example, the below query calculates the average for each Web Vital type (TTFB, FCP, LCP etc.) for a specific browser check.

sum by(type) (rate(checkly_browser_check_web_vitals_seconds_sum{name="Check Name"}[30m])) / sum by(type) (rate(checkly_browser_check_web_vitals_seconds_count{name="Check Name"}[30m]))

Check out the full docs right here.

This feature is available on all paid plans.

Questions or feedback? Join our Slack community.

We just released a new version of the Checkly CLI that supports TypeScript 5.x. This solves this GitHub issue raised by our users. This is the only major change in this release.

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

Questions or feedback? Join our Slack community.

Sometimes the stars align, and sometimes they just miss each other by a few days! We just snuck in the very latest @playwright/test version 1.38.1 into the 2023.09 runtime we released last week.

The Playwright team made a great video of the updates in this release.

The rest of the packages in 2023.09 stay the same. See the previous changelog entry for more details.

Our latest runtime, 2023.09, is now GA.

The new runtime includes a number of new libraries, plus updates to Playwright, Node, and more.

New libraries:

• dotenv - Improved support for managing sensitive data in your checks.

• ethers - Test & monitor your ethereum blockchain products and services.

• prisma - OSS ORM

• @t3-oss/env-nextjs - environment variable validation

• @xmldom/xmldom - W3C DOM for Node.js

• xml-encryption - W3C XML Encryption implementation for node.js

• zod - Typesafe schema validation

Updated libraries:

• Playwright

• Node 18.x

• @faker-js/faker

• @google-cloud/local-auth

• @opentelemetry/api

• @opentelemetry/sdk-trace-base

• aws4

• axios

• date-fns

• expect

• google-auth-library

• googleapis

• jose

• jsdom

• jsonwebtoken

• otpauth

• twilio

• xml-crypto

Check all the details in our runtime specs documentation.

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

Increase reliability and confidence by effortlessly monitoring your backup jobs, database updates, imports, and other recurring tasks with our latest check type.

With GA, heartbeat checks have an updated UI and are fully supported on Checkly, including in our analytics API, dashboards, maintenance windows, and more.

Create private or public dashboards for your users or teams to showcase your backend status. Plan your upgrades without worrying about false alerts, and import run data into your analytics platform.

Getting started

Heartbeat checks await pings from external sources, with each check having a unique URL the job pings when successful. This ping URL be can be added to a wide variety of jobs. Here is a simple example of adding a heartbeat ping to any bash cron job scheduled in your crontab:

# run_backup.sh

PING_URL=https://ping.checklyhq.com/87c05896-3b7d-49ae-83ff-5e81323a54c4

curl -m 5 --retry 3 $PING_URL;

And if you are using node:

const axios = require('axios');

axios.get('https://ping.checklyhq.com/87c05896-3b7d-49ae-83ff-5e81323a54c4').then(resp => {
    console.log(resp.data);
})

Unsure of how to add a ping event to your scheduled job? Our documentation covers multiple programming and scripting languages, getting you started in no time.

Looking for help?

• General documentation.

• Check out the documentation how to create heartbeat checks with our CLI and Terraform provider.

• If you have requests for guides or additional examples, join our Slack community and let us know.

Heartbeat checks are available on the following plans:

• Team with a quota of 15 Heartbeat checks.

• Enterprise with a custom quota.

You can now define three distinct retry strategies for API checks, browser checks and check groups. Each strategy, Fixed, Linear or Exponential has different backoff characteristics to cover different retrying scenarios.

You can also toggle if retries are performed from the initial failing location, or from a different location picked from your configured check locations.

With this new feature, you can reduce alert fatigue and increase the signal vs. noise level of alert messages.

Check out our updated documentation for more details.

You can configure your retry strategies also via:

• Checkly CLI v4.1.0

• Checkly Terraform provider v1.7.1

• Checkly public API

This feature is available on all plans except for plans marked as "deprecated"

Questions or feedback? Join our Slack community.

CLI version v4.1.0 just came out and provides support for the new smart retry strategies we just released. Adding a retry strategy is simple. Just use the RetryStrategyBuilder and add it to any ApiCheck, BrowserCheck or CheckGroup construct.

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

new ApiCheck('retrying-check-01', {
  name: 'ACME API production',
  retryStrategy: RetryStrategyBuilder.linearStrategy({
    baseBackoffSeconds: 30,
    maxRetries: 4,
    sameRegion: false,
  }),
  request: {
    method: 'GET',
    url: 'https://danube-web.shop/api/books'
  }
})

Read more about smart retries and retry strategies on our changelog.

Further enhancements and fixes include:

• HeartbeatCheck 's now print their ping URL to the console on creation.

• HeartbeatCheck's are now part of our advanced example repo.

• Various bugfixes on timeouts and typos.

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

Questions or feedback? Join our Slack community.