What is Monitoring as Code?
Monitoring as Code is a transformative approach to maintaining the reliability and performance of modern web applications by integrating monitoring processes directly into the software development lifecycle. This method is fully compatible with Infrastructure as Code (IaC) and configuration management tools, allowing your monitoring solution to be managed alongside other infrastructure components.Key Aspects of Monitoring as Code:
- Developer-First Monitoring:
- Seamless Integration: Checkly allows developers to define and manage their monitoring configurations alongside their application code. This means monitoring scripts and configurations can be version-controlled, reviewed, and tested just like any other part of the codebase.
- CI/CD Pipeline Support: With Checkly, you can embed monitoring checks directly into your CI/CD pipelines. This ensures that every deployment is automatically verified against your monitoring criteria, reducing the risk of undetected issues reaching production and enabling hassle-free continuous delivery.
- Programmatic Configuration:
- Infrastructure as Code (IaC) Compatibility: Checkly’s API and CLI tools make it easy to programmatically set up and manage monitoring. This aligns with the principles of IaC, allowing teams to define their monitoring infrastructure using code, ensuring consistency and reproducibility across environments.
- Programmable Monitoring Checks: Define advanced monitoring checks using JavaScript and TypeScript. This flexibility enables you to create highly specific and complex checks tailored to your application’s unique requirements.
Infrastructure-as-Code (IaC)
We’ve released our brand new CLI and recommend giving it a try for the best Monitoring as Code experience. Please visit our documentation if you want to learn more about the pros & cons of the Terraform provider vs. the CLI for code monitoring automation. Historically, IT infrastructure has been provisioned manually, both on-premise and in the cloud. This presented several challenges, including fragmented workflows, lack of transparency, and scalability issues. In response to these problems, the last few years have seen a shift to the Infrastructure-as-Code (IaC) paradigm, in which large-scale systems are declared in configuration files, a method that code monitoring adopts to enhance operational efficiency. A new generation of tools has emerged to serve this use case, the most notable example of which is HashiCorp Terraform. Terraform provides a CLI workflow that allows users to specify the desired final infrastructure setup, handling all the intermediate steps and processes needed to achieve it, embodying the principle of monitoring as code.
Monitoring the IaC way
Setting up monitoring tools and monitoring in general can present some of the same issues as provisioning infrastructure. This becomes apparent when scaling beyond the initial rollout or proof-of-concept phase, as monitoring as code helps manage the growing scope and maintenance needs efficiently. Monitoring-as-Code learns from IaC and brings your monitoring config closer to your application and your development workflows. How? By having it also declared as code, much like you would do with any kind of IT infrastructure.Why Monitoring-as-Code
What does one gain when moving from a manual process to a Monitoring-as-Code approach? The main advantages are:- Better scalability through faster provisioning and easier maintenance.
- Better history and documentation: config files can be checked into source control.
- Shared monitoring setup visibility (and easier shared ownership) in DevOps teams.
Monitoring-as-Code with Checkly
Users who have just started out will be familiar with creating checks, groups, alert channels and other resources through the Checkly UI. However, the official Terraform provider for Checkly allows for these elements to be declared as code, streamlining the provisioning and deployment of active monitoring setups, a practice central to code monitoring. You can find the Checkly Terraform provider on the official Terraform registry.
Monitoring an e-commerce website - as code
Exploring code monitoring in practice, we set up a small monitoring configuration for our demo e-commerce website using Terraform and Playwright scripts, showcasing the efficiency, reliability and scalability of monitoring as code.Setting up our Terraform project
For our example we will be creating browser checks using Playwright scripts we have previously written as part of our Playwright guides.login.spec.js
mkdir checkly-terraform-example && cd $_
To keep things easy, we create a subdirectory…
mkdir scripts
…and copy all our scripts from above into separate files, for example login.spec.js
.
Next up, we want to create our main.tf
file and include the basic configuration as follows:
main.tf
terraform init
After a few seconds, you should see a similar message to the following:
Creating our first browser checks
In the same file, right below our initial instructions, we can now add resources one after the other. They will be browser checks based on the Playwright scripts we previously stored in thescripts
directory. Here is what each resource could look like:
main.tf
terraform plan
.
Terraform will determine all the needed changes to be performed to replicate our monitoring software configuration on Checkly. In doing so, we will be asked for our Checkly API key, which we can find under our account settings as shown below. Not on Checkly yet? Register a free account and enjoy your free monthly checks!

export TF_VAR_checkly_api_key=<YOUR_API_KEY>
.
terraform apply
. We might be asked for one final confirmation in the command prompt, after which we will be greeted by the following confirmation message:

Monitoring API correctness and performance
Browser checks are now there to keep us informed on the status of our key website flows. What about our APIs, though? Whether they make up the foundation of our service or they are consumed directly by the customer, we need to ensure our endpoints are working as expected. This is easily achieved by setting up API check resources.main.tf
terraform plan
, followed by terraform apply
to see the new check on Checkly:

Alerting
Now that we have our checks in place, we want to set up alerting to ensure we are informed as soon as a failure takes place. Alert channels can be declared as resources, just like the checks. Let’s add the following to ourmain.tf
file:
main.tf
main.tf
terraform plan
and terraform apply
sequence will apply the changes on our Checkly account:

Expanding our setup
As our setup expands, we might want to deploy additional tools to make our lives easier. We could:- Iterate over existing Playwright scripts and create multiple checks while declaring only one resource.
- Group checks together to better handle them in large numbers.
- Use code snippets to avoid code duplication and reduce maintenance.
- Move your workflow to Terraform Cloud to easily collaborate with your team when managing your Monitoring-as-Code configuration.