terraform-provider-sentry

The sentry_organization_repository resource allows you to manage Sentry's integrations with source code management (SCM) systems like GitHub, GitLab, Bitbucket, and Azure DevOps (VSTS). This enables Sentry to link specific repositories to your Sentry organization.

Supported Integration Types

• github
• github_enterprise
• gitlab
• vsts (Azure DevOps)
• bitbucket
• bitbucket_server

# GitHub Example
data "sentry_organization_integration" "github" {
  organization = "my-organization"
  provider_key = "github"
  name         = "my-github-organization"
}

resource "sentry_organization_repository" "github" {
  organization     = "my-organization"
  integration_type = "github"
  integration_id   = data.sentry_organization_integration.github.id
  identifier       = "my-github-organization/my-github-repo"
}

Use the sentry_organization_member resource to manage users at the organization level in Sentry.

Note: If your goal is to add a member to a specific team rather than the entire organization, use the sentry_team_member resource instead.

# Create an organization member
resource "sentry_organization_member" "john_doe" {
  organization = "my-organization"

  email = "test@example.com"
  role  = "member"
}

The action_filters block defines the logic used to evaluate whether an action should be triggered.

Logic Types (logic_type):

• any: Returns true if any condition is met.
• any-short: Returns true and stops evaluating as soon as one condition is met.
• all: Returns true only if all conditions are met.
• none: Returns true if none of the conditions are met; returns false immediately if any are met.

Conditions: Conditions are evaluated within the action_filters block to determine if the associated actions should fire. Supported condition types include age_comparison, assigned_to, event_attribute, event_frequency_count, issue_priority_greater_or_equal, issue_type, and more.

The owner block determines which entity Sentry will assign new issues to when a monitor fails. You can assign issues to either a team or a specific user.

• team_id (String): The team internal ID. Conflicts with user_id.
• user_id (String): The user ID. Conflicts with team_id.

owner {
  team_id = "TEAM_ID"
}

# OR

owner {
  user_id = "USER_ID"
}

The assertion_json argument defines the conditions that must be met for an uptime check to be considered successful. It is a JSON string representing a tree of operations.

Using Provider Helpers (Recommended)

You can use provider::sentry functions to construct the JSON safely:

assertion_json = provider::sentry::assertion(
  provider::sentry::op_and(
    provider::sentry::op_status_code_check("greater_than", 199),
    provider::sentry::op_status_code_check("less_than", 300),
  )
)

Raw JSON Format

Alternatively, you can provide the raw JSON string. The structure requires a root key containing the top-level operation:

{
  "root": {
    "op": "and",
    "children": [
      {"op": "status_code_check", "operator": {"cmp": "greater_than"}, "value": 199},
      {"op": "status_code_check", "operator": {"cmp": "less_than"}, "value": 300}
    ]
  }
}

Percentage change monitors alert you when a metric changes by a certain percentage over a defined time window. This is useful for detecting sudden spikes or drops relative to recent history.

Key configuration:

• issue_detection.type: Set to "percent".
• issue_detection.comparison_delta: The time window in seconds used for the comparison (e.g., 3600 for the previous hour).
• condition_group.conditions: Use types like lt or gt to define the percentage delta.

resource "sentry_metric_monitor" "change" {
  # ... other required fields ...
  condition_group = {
    conditions = [
      {
        type             = "lt"
        comparison       = 50
        condition_result = 75
      }
    ]
  }
  issue_detection = {
    type             = "percent"
    comparison_delta = 3600
  }
}

The schedule block defines how often the monitor runs. You must choose between a crontab expression or an interval-based schedule.

Crontab Schedule

Use the crontab argument with standard crontab syntax (e.g., 0 0 * * *). This conflicts with interval-based settings.

Interval Schedule

Use interval_value and interval_unit together. This conflicts with crontab.

• interval_value (Number): The numeric value of the interval.
• interval_unit (String): The unit of time. Valid values are: year, month, week, day, hour, and minute.

### Crontab Example
schedule {
  crontab = "0 0 * * *"
}

### Interval Example
schedule {
  interval_value = 15
  interval_unit  = "minute"
}

Static threshold monitors use absolute values to trigger issues. This is best for non-seasonal data where you want to alert when a metric exceeds or falls below a specific number.

Key configuration:

• issue_detection.type: Set to "static".
• condition_group.conditions: Define thresholds using types like gt (greater than), lt (less than), gte (greater than or equal), lte (less than or equal), or eq (equal).
• comparison: The numeric value to compare against.

resource "sentry_metric_monitor" "threshold" {
  # ... other required fields ...
  condition_group = {
    conditions = [
      {
        type             = "gt"
        comparison       = 100
        condition_result = 75
      },
      {
        type             = "lte"
        comparison       = 50
        condition_result = 0
      }
    ]
  }
  issue_detection = {
    type = "static"
  }
}

Dynamic monitors use Sentry's automated anomaly detection to identify deviations from seasonal or noisy data patterns.

Key configuration:

• issue_detection.type: Set to "dynamic".
• condition_group.conditions: Use the anomaly_detection type.
• comparison_sensitivity: Controls responsiveness (low, medium, high).
• comparison_threshold_type: Determines if you alert on movement above, below, or above_and_below the threshold.

resource "sentry_metric_monitor" "dynamic" {
  # ... other required fields ...
  condition_group = {
    conditions = [
      {
        type                      = "anomaly_detection"
        comparison_sensitivity    = "high"
        comparison_threshold_type = "above_and_below"
        condition_result          = 75
      }
    ]
  }
  issue_detection = {
    type = "dynamic"
  }
}

Use the sentry_organization_member data source to fetch details about a specific member within a Sentry organization using their email address. This is useful for looking up a member's id, internal_id, or role for use in other Terraform resources.

data "sentry_organization_member" "default" {
  organization = "terraform-provider-sentry"
  email        = "test@example.com"
}

To import an existing dashboard into Terraform, use the terraform import command with the format org-slug/dashboard-id. The dashboard-id can be found in the URL of the dashboard in the Sentry UI: https://sentry.io/dashboard/[dashboard-id].

# import using the dashboard id from the URL:
# https://sentry.io/dashboard/[dashboard-id]
terraform import sentry_dashboard.default org-slug/dashboard-id