.avif)
.png){kind=icon}
.png){kind=icon}
Infrastructure as Code (IaC) is no longer a niche practice; it's the standard for managing modern cloud environments. However, as infrastructure scales, a new challenge emerges: configuration drift. This happens when the configuration in your critical tools, like an incident management platform, falls out of sync with your actual infrastructure. The solution is to extend IaC principles to your operational tooling through Incident Management as Code (IMaC) [1]. This approach allows teams to manage incident response processes with the same rigor and automation as their infrastructure. The Rootly Terraform Cloud integration enables exactly this, letting you define and manage your entire incident response setup as code.
What is the Rootly Terraform Cloud Integration?
The integration is an official Terraform provider that empowers DevOps and Site Reliability Engineering (SRE) teams to manage their Rootly resources declaratively. Using the provider, you can define and control services, functionalities, severities, teams, custom fields, and even entire automated incident response workflows.
The primary benefit is creating a single source of truth for your incident management configuration, version-controlled in Git right alongside your application and infrastructure code. This is all made possible through the official Rootly Terraform provider, which is actively maintained by Rootly and available on GitHub [2].
IaC-Driven Incident Response: Automate Workflows as Code
The power of the integration is fully realized with iac-driven incident response workflows rootly. Instead of manually navigating a UI to build automation rules, you can create rootly code-based workflow definitions directly in your Terraform files.
This code-first approach offers several advantages:
- Consistency: Ensure every environment (development, staging, production) has the exact same incident response logic applied.
- Peer Review: Changes to incident workflows can be reviewed and approved through pull requests, just like any other code change, improving quality and collaboration [3].
- Auditability: Git history provides a clear, immutable log of who changed what, when, and why.
This method helps you build robust incident response playbooks-as-code that are always synchronized with your infrastructure [4]. These automated workflows are a key component of the incident lifecycle managed within Rootly, from triggering to resolution.
How Rootly Automates Infra Metadata Syncing
A common pain point for engineering teams is keeping incident management tooling aware of infrastructure changes. This is where rootly infra metadata syncing automation comes in.
Consider a typical scenario: A developer provisions a new microservice using Terraform. Traditionally, they would then have to manually log into their incident platform to register the new service so it can be tagged in future incidents. This manual step is slow and prone to human error.
The Rootly Terraform provider eliminates this friction. The definition for the new Rootly service can live in the same Terraform module as the microservice itself. When terraform apply runs, it not only creates the infrastructure (for example, a Kubernetes deployment) but also automatically registers the service in Rootly [1]. This ensures your incident management platform always has an up-to-date catalog of your infrastructure without any manual intervention.
Rootly Terraform Module Examples for 2025
This section provides practical rootly terraform module examples to get you started. For a complete list of resources and configuration options, refer to the official Rootly Terraform documentation.
1. Configuring the Rootly Provider
First, you need to configure the Terraform provider. In your main.tf or versions.tf file, require the rootlyhq/rootly provider and configure it. It's a best practice to set your API token using the ROOTLY_API_TOKEN environment variable rather than hardcoding it in your configuration.
terraform {
required_providers {
rootly = {
source = "rootlyhq/rootly"
version = "~> 3.0"
}
}
}
provider "rootly" {
# The API token can be set here, but using the
# ROOTLY_API_TOKEN environment variable is recommended.
# api_token = "rk-..."
}
2. Defining Incident Resources (Services, Functionalities, Severities)
These resources are the building blocks for classifying and triaging incidents. You can define them directly in your .tf files.
Service:
resource "rootly_service" "api" {
name = "API"
slug = "api"
}
Functionality:
resource "rootly_functionality" "user_authentication" {
name = "User Authentication"
slug = "user-authentication"
}
Severity:
resource "rootly_severity" "sev1" {
name = "SEV1"
slug = "sev1"
description = "Critical issue with widespread customer impact."
color = "#ff0000"
}
3. Creating a Code-Based Workflow Definition
Here is a powerful example of defining an automation workflow as code. This workflow will automatically create a Jira issue whenever an incident is created in Rootly. This is a direct demonstration of how to implement rootly code-based workflow definitions.
resource "rootly_workflow_incident" "auto_create_jira_ticket" {
name = "Auto-create Jira Ticket for New Incidents"
description = "When an incident is created, automatically create a corresponding Jira ticket."
trigger_params = {
triggers = ["incident_created"]
incident_conditions = []
}
enabled = true
# This references the task defined below
task_ids = [
rootly_workflow_task_create_jira_issue.create_ticket.id
]
}
resource "rootly_workflow_task_create_jira_issue" "create_ticket" {
task_params = {
title = "Incident {{ incident.number }}: {{ incident.title }}"
project_key = "ENG"
issue_type_id = "10001" # This ID corresponds to "Task" or "Bug" in your Jira project
description = "An incident has been declared. Please investigate.\n\nSummary: {{ incident.summary }}\nLink to incident: {{ incident.url }}"
priority_name = "High"
}
skip_on_failure = false
}
In this example, the rootly_workflow_incident resource defines the trigger (an incident is created). The rootly_workflow_task_create_jira_issue resource defines the action, using template variables like {{ incident.title }} to dynamically populate the Jira ticket with data from the Rootly incident.
Advanced Topics and Integrations
OpenTofu Compatibility
For organizations using OpenTofu, the open source fork of Terraform, the Rootly provider remains fully compatible. It is available on the official OpenTofu Registry [5]. This ensures your team can continue managing incident response as code, regardless of your chosen IaC tool.
Managing Existing Resources: From Terraformer to import
Previously, teams might have used the Terraformer CLI tool to import existing Rootly resources into Terraform state. While this tool was helpful, it is now deprecated. The modern, recommended approach is to use Terraform's built-in import blocks. This is a more standard and robust method for bringing existing configurations under IaC management, aligning with best practices in the Terraform ecosystem.
Conclusion: Build a More Resilient, Custom-Fit Incident Response Engine
Using the Rootly Terraform Cloud integration is a significant step toward maturing your incident response practices. It eliminates configuration drift, enforces consistency through peer-reviewed changes, and automates metadata synchronization to keep your systems in lockstep. Managing incident response as code is a hallmark of high-performing SRE and DevOps teams.
This IaC-driven approach is a core part of Rootly's flexible, API-first philosophy. It allows you to move beyond rigid, UI-only configurations and build a truly custom incident response engine that fits your team's exact needs. To learn more about what's possible, explore the Rootly API and its powerful automation capabilities.