The monitoring as code workflow enables developers to code, test and deploy your entire monitoring infrastructure. This guide explains how to leverage TypeScript/JavaScript to configure your monitoring setup dynamically.
With the release of the Checkly CLI, monitoring as code (Mac) enables you to code, test, and deploy your entire monitoring setup. Use the CLI to programmatically create monitoring resources, test these in CI/CD development workflows and then deploy them to the Checkly cloud to monitor your sites and APIs.
One of the CLI’s key features is that it’s not based on static configuration files but bets on dynamic JavaScript/TypeScript execution. A Checkly monitoring as code flow is highly programmable and unlocks tailored monitoring setups that live in your application code base.
Learn how to program your monitoring infrastructure in this guide or watch the video below.
Every Checkly project is configured via a checkly.config
file. It holds meta information such as the project name, default values for your API and browser checks, and, most importantly, your check files’ location (*.check.ts
).
The checks.checkMatch
property accepts a glob pattern to specify which files should be executed to test and deploy your monitoring infrastructure.
Find out more about all the project configuration options in the docs.
Place your check files next to your running application code or in a dedicated monitoring directory; it’s up to you!
When the Checkly CLI executes a check file, the file must import and initialize Checkly constructs to create resources such as browser and API checks, groups, and alert channels.
The example above initializes a CheckGroup
that an ApiCheck
references. These two resources can then be tested via npx checkly test
and deployed to the Checkly cloud via npx checkly deploy
.
If you want to see an opinionated Checkly CLI project example, check our advanced CLI template.
But what if you want to create your monitoring setup depending on configuration files or environment variables?
Checkly’s TypeScript-first CLI workflow enables you to program your monitoring infrastructure.
The monitoring as code workflow is based on TypeScript/JavaScript execution. Import and read files, create monitoring resources conditionally, or iterate over data to not repeat yourself; it enables you to tailor your Checkly setup to your project’s requirements.
Let’s look at examples and monitoring as code patterns.
When adopting modern CI/CD development practices and using preview environments, leverage environment variables to test your resources with the Checkly cloud.
By using an ENVIRONMENT_URL
environment variable and falling back to a production URL, your check files can be used to test preview deployments and monitor your production site and APIs.
Environment variables enable you to configure your monitoring resources, test them and then update your entire Checkly setup in a production deployment.
Before jumping all onto environment variables, understand the difference between local and remote environment variables.
But monitoring as code isn’t only about configuring your environment and interpolating values.
Suppose you want to create Checkly resources in bulk; JavaScript/TypeScript enables you to define your entire monitoring setup programmatically. Creating multiple resources is only one JavaScript loop away.
Similarly, if you want to read and parse files to create monitoring resources, leverage the fs
module and the JavaScript ecosystem.
Reuse infrastructure as code configuration files (such as YAML) to configure your monitoring setup and avoid duplicated resource definitions.
If you’re using a file-based routing framework such as Next.js, use the fs
module to automatically read and parse directories to create monitors for the resulting routes and pages.
But in some cases, you must perform asynchronous JavaScript operations, such as requesting files from the network to define your monitoring.
Do check files allow asynchronous operations, too?
Check files can wait for asynchronous operations. Export a promise or async function as default object from your check files, and the CLI will wait for your operations to finish.
The example above fetches an API definition from the network via a getAllEndpoints
helper function and automatically creates the monitoring resources. Use async
and await
for perform any async operation.
Monitoring as code is more than writing config files. Read project code, iterate, or fetch data — the CLI’s JavaScript and TypeScript execution enables you to tailor your monitoring setup to your existing application code (and not the other way around).
What are your preferred monitoring as code patterns? Join the Checkly community, let me know and I’m happy to include your favorite pattern in this guide.
Understand monitoring as code (MaC) via our Checkly CLI.
Learn end-to-end monitoring with puppeteer and playwright to test key website flows.
OpenAPI and Swagger help users design and document APIs in a way that is readable from both humans and machines.