Giovanni Rago

Managing large numbers of website monitoring checks by hand quickly becomes cumbersome. Luckily, Checkly's REST API allows us to automate most of the repetitive steps. Building on that API, the Checkly Terraform Provider takes automation one step further, enabling users to specify their synthetic transaction monitoring setup as code.

In this article, we will be building on top of John Arundel's great intro from a few months back and showing how to manage multiple checks using groups and shared code snippets.

Creating multiple transaction monitoring checks

Since our previous post on Terraform showed how to create API checks already, this one will use browser checks for website transaction monitoring as examples instead. The setup is similar: we only need to change the check type and add our Puppeteer or Playwright script rather than the API check's request. Let's create two browser check resources in our main.tf file:

Notice that we are loading the scripts from external files to keep things nice and tidy. In this case we are using E2E examples from theheadless.dev. Here is checkout.js:

Supposing we have already run the terraform init command to prepare our local directory, we can now go ahead and first create a new plan with terraform plan -out tf.plan, then subsequently apply it with terraform apply tf.plan. This is the result on Checkly:

To see our changes applied, we will be running the same sequence of commands after each update to our main.tf file.

If our scripts are somehow related, we might want to group them together to make them easier to manage. We will see the whys and hows in the following paragraphs.

To group our checks, we need to do two things:

Create an additional resource for the group.

Include our checks in the group by adding the group.id property set to the ID of the group resource.

After our changes, the main.tf file will look like this:

We are now provisioning two browser checks as part of a single group:

Aside from providing a conceptual abstraction that can be helpful in handling larger numbers of checks, groups override and centralise the following check settings:

API check defaults: base request config, assertions and setup & teardown scripts.

Environment variables, adding to the existing global environment variables that might be set.

Data center locations, fully overriding the check's own config.

Alert setting and alert channels, fully overriding the check's own config.

CI/CD triggers, which enable running all checks in one group with the same trigger.

Additionally, having all checks grouped together allows us to activate or mute them all in one go (see activated and muted within the group in the code block above).

When creating a group, you are free to include whichever checks you like. Ultimately, you will want to find a structure that works for you. Some examples from Checkly users:

Based on the target (website, webapp, API) being checked, when multiple ones are in scope, e.g.: each webapp being monitored has a dedicated group.

Based on the component, endpoint or flow that is being checked, e.g.: all checks checking for checkout functionality are grouped together; all checks running against the /users endpoint of an API are in the same group.

Based on the function of the check, e.g. all checks focusing on load time are grouped together, same with the ones checking functional flows.

Iterating through scripts for shorter config

When we have multiple checks which share most of their configuration, we do not need to declare one resource per check. In the case of our example, we are creating checks that differ only in their name and script. Therefore, we will place our script files in a separate directory, then we will use the foreach construct to iterate through them.

We are now creating as many checks as there are scripts in our folder, while specifying a single resource in our Terraform file. This is particularly helpful when the number of checks is significant.

We still have another opportunity for improvement: our scripts include duplicated code, namely the "add-to-cart" procedure at the beginning. Code duplication makes maintenance expensive (not to mention tedious) and creates room for error. We can avoid this issue by wrapping the duplicated code in a snippet:

This way, if the "add-to-cart" procedure changes at some point the future, we will only need to apply changes in one place.

Code snippets have their own resource. Here we are importing the snippet from an external file:

Using the partials notation, it is enough to add the {{> snippet_name }} call to have the same code snippet imported into one or more script.

This is what checkout.js looks like with the snippet:

After applying all the above changes, our main.tf will look as follows:

How to avoid script and config code duplication

As is almost always the case with automation, a good setup needs a certain amount of future-proofing: we put a bit of additional work in today to save ourselves from putting in a lot of work tomorrow. Terraform allows us to do just that and easily manage our synthetic transaction monitoring setup on Checkly, be it ten or ten thousand checks.

Would like to see a more complex, fully working example, along with the full code nicely packaged in an example repository? Stay tuned for our next post! In the meantime, be sure to play around with the Terraform Provider and find the setup that works for you. Have fun!

banner image: "Futago Island - Moonlight at Matsushima". Kawase Hasui, 1933, Japan. Source

Synthetic transaction monitoring at scale with Terraform and Checkly

Detect

Communicate

Resolve

Monitoring as Code

Developers

Resources

Community

Synthetic transaction monitoring at scale with Terraform and Checkly