Configure Rootly with Terraform: Automation Blueprint

Infrastructure as Code (IaC) is the practice of managing your technology infrastructure using code instead of manual setup. When you apply this concept to incident management, it becomes a powerful method for standardizing and automating how your team handles outages. Using Terraform to manage your Rootly configurations enables you to bring automation, version control, and consistency to your incident response processes.

This article serves as a blueprint, providing practical examples and best practices to guide you through implementing rootly configuration via terraform automation.

Why Use IaC-Driven Incident Response with Rootly and Terraform?

Combining Rootly and Terraform transforms your incident management from a series of manual clicks into a repeatable, code-driven process. The core benefits are significant for any engineering team looking to improve its reliability.

• Consistency and Scalability: Terraform ensures that every part of your incident management setup is configured identically across all environments. This gets rid of configuration drift and makes it easy to scale your processes as your teams and services grow.
• Version Control: By storing your Rootly configurations in a version control system like Git, you get a full history of every change. This allows for collaborative reviews, change tracking, and the ability to quickly roll back to a previous state if something goes wrong.
• Reduced Manual Effort: Automating the setup of services, workflows, and severities eliminates the need for manual configuration in the Rootly UI. This not only saves valuable engineering time but also drastically reduces the risk of human error.
• Enhanced Reliability: When your incident process is defined in code, it becomes more robust, predictable, and easier to audit. Anyone can see exactly how a response is configured to run, leading to greater trust and reliability.

In Rootly, every incident is represented as an incident object that contains all the crucial details about what happened. With Terraform, you can manage the properties and workflows associated with these objects entirely through code.

Getting Started: Prerequisites and Provider Setup

Before you can start managing Rootly with Terraform, you need to connect the two. The setup process is straightforward.

First, make sure you have the following prerequisites:

• Terraform (latest version) installed.
• A Rootly account with admin permissions.
• A Rootly API token from your account settings.

Next, you need to configure the Rootly provider in your Terraform project. Add the following block to your versions.tf or main.tf file.

terraform { required_providers { rootly = { source = "rootlyhq/rootly" version = "~> 2.26.0" } } } provider "rootly" { # We recommend setting the API token via an environment variable # for security. Export it in your terminal: # export ROOTLY_API_TOKEN="your_api_token" }

For better security, it's best to set your API token using the ROOTLY_API_TOKEN environment variable instead of hardcoding it in your configuration files.

For complete setup details, you can always refer to the official documentation on our Terraform integration. The Rootly Terraform provider is open source and available on GitHub, where it has over 612 commits [1]. It is also compatible with the OpenTofu registry for teams using that fork of Terraform [2].

A Practical Blueprint: Rootly Terraform Module Examples for 2025

This section provides a step-by-step guide with code examples to configure core Rootly components. These rootly terraform module examples 2025 show how you can build a complete incident management framework using code.

Defining Foundational Resources: Services, Severities, and Functionalities

The first step in codifying your incident process is to define the building blocks of your framework. These are the core components your team will use when declaring and managing incidents.

• Severities: Define the impact levels for your incidents (for example, SEV0 for a critical outage, SEV2 for a minor issue).
• Services: List the technical services your organization maintains (for example, elasticsearch-prod or customer-postgresql-prod).
• Functionalities: Detail the specific capabilities that a service provides (for example, logging-in or add-items-to-cart).

Here’s how you can define these resources in Terraform:

# severities.tf resource "rootly_severity" "sev0" { name = "SEV0 - Critical" slug = "sev0" color = "#d93f3e" } resource "rootly_severity" "sev1" { name = "SEV1 - Major" slug = "sev1" color = "#f5a623" } # services.tf resource "rootly_service" "api" { name = "api-prod" slug = "api-prod" } resource "rootly_functionality" "login" { name = "user-login" service_id = rootly_service.api.id }

Building Custom Incident Forms

To ensure your team captures the right information during an incident, you can create custom fields for your incident forms. This lets you gather structured data that is specific to your environment.

This example shows how to create a multi-select field to specify which cloud provider regions are affected by an incident. The shown_at_start and required_at_end attributes control whether the field is visible or mandatory at different stages of the incident.

# form_fields.tf resource "rootly_form_field" "regions_affected" { name = "Regions Affected" field_type = "multi_select" shown_at_start = true required_at_end = false track_as_catalog = true } resource "rootly_form_field_option" "us_east_1" { form_field_id = rootly_form_field.regions_affected.id value = "us-east-1" } resource "rootly_form_field_option" "eu_west_2" { form_field_id = rootly_form_field.regions_affected.id value = "eu-west-2" }

Automating Your Incident Response Workflows

The real power of this method comes from building iac-driven incident response workflows rootly. You can define automated tasks that trigger based on specific incident conditions, ensuring a consistent and fast response every time.

This Terraform example creates a workflow that automatically opens a Jira issue as soon as a new incident is started. The trigger_params block defines the conditions that start the workflow. You can use template variables like {{ incident.title }} to dynamically pass incident data to other tools.

# workflows.tf resource "rootly_workflow_incident" "create_jira_issue" { name = "Create Jira Issue for New Incidents" description = "Automatically creates a Jira ticket when an incident is started." enabled = true trigger_params = { incident_conditions = [ "status = 'started'" ] } tasks = [ jsonencode({ task_type = "create_jira_issue" params = { project_key = "ENG" summary = "[Incident] - {{ incident.title }}" issue_type_id = "10001" # This ID can be found in your Jira settings } }) ] }

This is just one example. You can explore a wide range of automation possibilities with Incident Workflows to page on-call responders, spin up dedicated Slack channels, and much more.

Advanced Techniques and Best Practices

As your configuration grows, following best practices will help you keep your code clean and easy to manage.

Importing Existing Rootly Resources into Terraform

If you already have Rootly configured manually, you can bring those existing resources under Terraform management. The old terraformer-rootly CLI tool is now deprecated, though you can find more information about it for historical context on the Terraformer page.

The modern and recommended approach is to use terraform import blocks directly in your configuration files. This tells Terraform to "adopt" an existing resource. For example, to import an existing service, you would add a block like this to your .tf file and run terraform plan:

# Conceptual example for importing a service import { to = rootly_service.existing_service id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # The UUID of the service in Rootly }

Structuring Your Code for Maintainability

To keep your project organized, it's a good idea to split your configuration into logical files. This makes it easier to find and update specific resources.

• services.tf: for rootly_service and rootly_functionality resources.
• workflows.tf: for rootly_workflow_incident resources.
• variables.tf: for defining input variables.

For even greater reusability, you can group related resources into Terraform modules. For example, you could create a module for a new microservice that automatically bundles the Rootly service, its functionalities, and a standard set of incident workflows. It's helpful to know that when building modules, there are some known limitations in the underlying Terraform SDK, like handling diffs for list-type attributes [3].

Rootly in the Broader IaC Ecosystem

While Terraform is a popular choice for IaC, Rootly also integrates with other tools to fit your team's preferences. For teams that prefer using general-purpose programming languages like Python, Go, or TypeScript, a Pulumi provider for Rootly is also available [4]. You can use it to manage a variety of Rootly resources [5] such as services [6]. This flexibility ensures you can manage Rootly using the tools you're already familiar with.

Conclusion: Building a Resilient, Automated Future

Configuring Rootly with Terraform helps you build an incident management system that is version-controlled, scalable, and automated. By defining your response processes as code, you reduce manual errors, empower your teams with consistent workflows, and strengthen the overall reliability of your systems.

The best way to get started is to codify a small piece of your Rootly configuration, like your severities or a single service. From there, you can incrementally expand your codebase to automate more of your incident lifecycle.

To learn more and explore all available resources, check out the official Rootly Terraform provider documentation.

‍