Skip to main content
We maintain an official Terraform provider for incident.io. With this provider you can manage:
  • Incidents: custom fields, severities, incident roles, incident statuses, incident templates, announcement rules and announcement templates
  • On-call: schedules, schedule rotations and replicas, schedule sync rules and targets, escalation paths, escalation path templates, and pay configurations
  • Alerts: alert sources, alert source attributes, alert attributes, alert routes, team alert grouping preferences, and maintenance windows
  • Catalog: catalog types, their attributes, and catalog entries
  • Automation and access: workflows, policies, secrets, and API keys
This allows you to bring incident.io account configuration into the same code review and approval cycle as you’d use for other key infrastructure and allows syncing information about your infrastructure or organization into incident.io, such as a list of services or teams. Using Pulumi? See Manage your account with Pulumi. For resources like schedules, escalation paths, workflows, alert sources, and alert routes, you can configure them in the visual editor first and then export the generated Terraform config — so you don’t have to write it from scratch. As an example, this is how you might configure a custom field for affected services:
Whether a field is required and where it appears is no longer configured on the field itself — set that up in incident forms in the dashboard.
Full documentation on how to use the provider and all its resources can be found in the Terraform registry at incident-io/incident. This includes example code and attribute definitions. Example usage for incident custom fields If you need a refresher on how to provision your infrastructure with Terraform, check out Hashicorp’s tutorials and documentation.

Importing existing resources

If you already have configuration set up in the dashboard, you can bring it under Terraform management without recreating it. For workflows, schedules, escalation paths, alert sources, and alert routes, the easiest path is exporting from the dashboard (see below), which generates the resource block and the matching terraform import command for you. For everything else, or if you prefer to write the configuration yourself:
  1. Write a resource block matching your existing configuration
  2. Find the resource’s ID, from the dashboard URL or the API
  3. Import it into your Terraform state:
Or, on Terraform 1.5 and later, use an import block:
  1. Run terraform plan and adjust your configuration until the plan shows no changes
Each resource’s page in the registry documentation shows its import syntax.

Editing Terraform-managed resources in the UI

Once a resource is managed by Terraform, it’s locked in the dashboard by default — you can’t save changes directly. But you can still use the UI to compose changes visually:
  1. Open the resource (e.g. a schedule or escalation path) in the dashboard
  2. Make your changes in the visual editor
  3. Instead of saving, click Export to get the updated .tf configuration
  4. Review and apply via your normal Terraform workflow
This keeps Terraform as the source of truth while letting you use our powerful visual editor to draft changes.

Returning a resource to the dashboard

If you want to edit a Terraform-managed resource in the dashboard after all, you’ve got two options:
  • Keep managing it with Terraform, but leave it unlocked. Set unlock_in_dashboard = true on the resource. You’ll also want lifecycle { ignore_changes = [...] } naming the attributes you plan to edit in the dashboard, otherwise the next apply will revert your changes. Each resource’s page in the registry documentation says whether it supports unlock_in_dashboard.
  • Stop managing it with Terraform altogether. Click the Synced badge on the resource and choose Disconnect. Bear in mind Terraform still has the resource in its state, so the next apply would put it back and lock it again. Remove it from your state too, with a removed block or terraform state rm.