Terraform Opsgenie Provider: Complete Guide to IaC for Incident Management

Opsgenie provides incident management with on-call scheduling, alert routing, and escalation capabilities. Managing Opsgenie configuration through Terraform ensures your incident management setup is version-controlled and reproducible. The Opsgenie Terraform provider lets you interact with many resources supported by Opsgenie, such as users, teams, escalations, etc. You can easily manage your Opsgenie resources by codifying APIs into declarative configuration files to code, edit, review or version your configurations.

Provider Overview and Capabilities

The Opsgenie Terraform provider is available at the official repository. The release is available here: https://github.com/opsgenie/terraform-provider-opsgenie

Setup documentation and configuration details are referenced at the Terraform registry documentation for the provider.

Opsgenie Terraform provider creates and manages the following resources with Terraform.

Resource Category	Resources Supported
Identity	Users without User Contact API
Organization	Teams with or without members
Integration	API and Email Based Integrations
Workflow	Escalations
On-Call	Schedules
On-Call	Schedule Rotations
Configuration	Provider Configuration

The provider configuration requires an API key and an API URL. The API key can be obtained from Settings > API Key Management in Opsgenie.

If you are on EU instance, make sure that the api_url is given as api.eu.opsgenie.com.

Provider Configuration

Provider setup begins with declaring the required provider and configuring credentials.

hcl terraform { required_providers { opsgenie = { source = "opsgenie/opsgenie" version = "~> 0.6" } } }

hcl provider "opsgenie" { api_key = var.opsgenie_api_key }

hcl variable "opsgenie_api_key" { type = string sensitive = true }

An alternative provider block example shows explicit api_url:

hcl provider "opsgenie" { api_key = "<insert api_key>" # https://support.atlassian.com/opsgenie/docs/api-key-management/ api_url = "api.opsgenie.com" # can be a stage instance url for devs }

After adding respective terraform change files which you want to apply on your OG instance, run respective terraform commands to test the provider as per your convenience.

Install the currently available provider with

tf init

terraform plan

and terraform init will use providers from the configured paths in $HOME/.terraformrc

terraform will output an error if no provider is found in the dev_overrides path

Core Resources

Teams

Teams can be created with or without members and with role assignments.

hcl resource "opsgenie_team" { name = "Dev-Provider test team" description = "New team made using in-development OpsGenie provider" }

A more detailed team example with members:

hcl resource "opsgenie_team" "platform" { name = "Platform Engineering" description = "Responsible for core infrastructure and platform services" member { id = data.opsgenie_user.alice.id role = "admin" } member { id = data.opsgenie_user.bob.id role = "user" } member { id = data.opsgenie_user.charlie.id role = "user" } }

Data sources for users are used to resolve IDs:

hcl data "opsgenie_user" "alice" { username = "[email protected]" }

Additional teams can be defined similarly:

hcl resource "opsgenie_team" "backend" { name = "Backend Engineering" description = "Responsible for backend services and APIs" member { id = data.opsgenie_user.bob.id role = "admin" } }

Schedules and Rotations

On-call schedules are created with timezone, ownership and enablement.

hcl resource "opsgenie_schedule" "platform_oncall" { name = "Platform On-Call" description = "Weekly on-call rotation for platform team" timezone = "America/New_York" owner_team_id = opsgenie_team.platform.id enabled = true }

Rotations are defined within the schedule:

hcl resource "opsgenie_schedule_rotation" "platform_weekly" { schedule_id =

This guide covers creating teams, schedules, rotations, and routing rules.

Escalations and Integrations

The provider supports escalations as a managed resource. Integrations are supported for both API and Email Based Integrations.

Atlassian Operations Provider Migration

The Atlassian Operations Terraform Provider enables you to manage Jira Service Management resources, including users, teams, escalations, and more, directly through Terraform. If you're transitioning from Opsgenie to Jira Service Management or have recently completed the move, you can migrate your Opsgenie Terraform Provider configurations to the Atlassian Operations Terraform Provider. This ensures you can continue leveraging Terraform to interact with and manage your data seamlessly in Jira Service Management.

The provider is a functional replication of the now transitioned Opsgenie Provider.

We don’t track or manage Terraform Provider issues via GitHub. Instead, we use Atlassian’s public issue tracker and support portal so that all requests can be properly triaged and followed up.

Check existing bug reports and suggestions Please first check whether your request has already been reported here:

If you find an issue that matches what you’re seeing, please vote for it and watch it for updates. This helps us prioritise and keeps you informed.

If you don’t find a matching issue If nothing there matches your bug or feature request, please create a ticket with our Support team here:

Thank you again for your feedback and for helping us improve the Terraform Provider.

The provider is still under development. It currently supports the following resources:

Team
Schedule incl. Rotation
Escalation
Email Integration
API-Based Integration
Notification Rule
Routing Rule
Custom Role
Alert Policy
Notification Policy
User Contact

And the following data sources:

User*
Team
Schedule excl. Rotation

Due to the internal structure of the Operations, user is implemented solely as a data source and supports read operations only.

Both Alert Policies and Notification Policies support an optional order attribute to control the execution order of policies

Configure the Provider

To set up the Atlassian Operations Terraform Provider, add the atlassian-operations provider configuration to your required_providers block. Ensure that you configure the provider with valid credentials before using it.

For more information about the available resources and data sources, use the navigation menu on the left. Currently, the provider supports six resources and three data sources.

To get started with Terraform, refer to the get started tutorials

Set up your Terraform configuration

Required parameters

Cloud id

Find your site's Cloud ID at:https://my-site-name.atlassian.net/edge/tenantinfo

Domain name

Your site’s URL, e.g.,my-site-name.atlassian.net

email_address

Use your email address associated with your Atlassian account.API Token
An API token added to your Atlassian account

Migration from Opsgenie to All Quiet

Opsgenie Migration

Migrating from Opsgenie to All Quiet: The Terraform IaC Transformation Guide - Part I

A technical guide for DevOps and SRE teams: Learn how to migrate from Opsgenie to All Quiet using Terraform, transforming legacy ticketing-heavy structures into modern, developer-first IaC workflows.

By Nikolas Köppl · Go-to-market at All Quiet

Reviewed by Maximilian Beller · Co-Founder & CTO at All Quiet

Updated: Sunday, 11 January 2026

Published: Sunday, 11 January 2026

TL;DR

Migrating your on-call infrastructure to All Quiet allows you to strip away legacy administrative bloat and replace it with actionable notification logic directly in your Terraform or more precisely HashiCorp Configuration Language HCL. By shifting from Opsgenie's fragmented member management to All Quiet's team-centric operational settings, you reduce your lines of code while gaining deeper control over how incidents are handled.

Building on our high-level look at why SRE teams are leaving the Atlassian ecosystem, it's time to get into the technical weeds. If your on-call setup is currently codified in HCL, your "checklist" isn't a spreadsheet, it's a mapping of Terraform resources. For DevOps and SRE teams, this migration is a chance to move from a legacy, ticketing-heavy structure to a modern, developer-first IaC workflow.

Resource Comparison Table

Feature	Opsgenie Provider	Atlassian Operations Provider
Users	Managed resource without User Contact API	Data source read only
Teams	With or without members	Supported resource
Schedules	Supported resource	Schedule incl. Rotation
Schedule Rotations	Supported resource	Included with Schedule
Escalations	Supported resource	Supported resource
Integrations	API and Email Based	Email Integration, API-Based Integration
Notification Rules	Not listed	Notification Rule
Routing Rules	Not listed	Routing Rule
Alert Policies	Not listed	Alert Policy
Notification Policies	Not listed	Notification Policy

Conclusion

The Opsgenie Terraform provider provides declarative management for users, teams, escalations, schedules, schedule rotations, and integrations through codified API interactions. Configuration relies on an API key obtained from Settings > API Key Management in Opsgenie and an API URL, with api.eu.opsgenie.com required for EU instances.

As organizations transition away from Opsgenie, migration paths are available. The Atlassian Operations Terraform Provider enables continued Terraform usage for Jira Service Management resources, including teams, escalations, and more, with required parameters of Cloud id, Domain name, email_address, and API Token. The provider replicates the Opsgenie Provider functionally and supports Team, Schedule incl. Rotation, Escalation, Email Integration, API-Based Integration, Notification Rule, Routing Rule, Custom Role, Alert Policy, Notification Policy, and User Contact resources.

For teams moving to All Quiet, Terraform remains the transformation mechanism, allowing legacy ticketing-heavy structures to be replaced with modern, developer-first IaC workflows and team-centric operational settings.