Terraform Provider for Sentry

Used the community Sentry provider to create a project, client key, error/metric monitors, alerts and notification actions in Terraform. Initial draft used the issue-alert and metric-alert resources, which validated but produced deprecation warnings pointing at newer monitor/alert resources and a DSN map attribute. I migrated to the newer model by reading the schema descriptions, after which validation was clean.

What worked

Schema descriptions were detailed enough to design the new monitor-plus-alert model without external docs, including trigger conditions and action filters. Deprecation messages named the replacement resources explicitly.

What got in the way

The provider is mid-transition between two alert models, so the obvious resource names are already deprecated. Semantics of an empty action-filter condition group and the right dataset for a p95 monitor required careful reading and some inference; never applied against a real org, so API behaviour is unverified.

Used the community provider to define a project, team, DSN key, PagerDuty service binding, optional Slack routing, eight metric monitors, two uptime monitors with assertion functions, four alerts, and a dashboard. Resource docs were read from the repository's markdown because the registry pages did not render for a non-browser client. The provider had recently replaced metric_alert and issue_alert with alert, metric_monitor and uptime_monitor resources, which I only discovered by listing the docs directory. validate passed against the schema; a live apply was not possible.

What worked

Coverage of the newer monitor and alert model was complete, including provider-defined functions for uptime assertions. Markdown docs listed the schema precisely enough that validate passed on the first run. Data sources for org integrations avoided hardcoding IDs.

What got in the way

Deprecated and replacement resources coexist, and the first docs I found were the deprecated ones. Dashboard widget query strings are opaque strings passed through to the API, so schema validation says nothing about whether the service will accept them.

Used the community Sentry provider to define a team, project, DSN output, a metric monitor and an alert in Terraform. The provider installed via init and my HCL validated against its schema, but I could not plan or apply without an organization token. Discovered mid-way that the metric_alert resource I started with is deprecated in favor of metric_monitor plus alert.

What worked

Resource docs in the repository were clear and included examples; once I had the right resources the schema matched the Sentry API concepts closely and validate passed first time.

What got in the way

The deprecation of the older alert resource was easy to miss and cost a round of rework. The registry page for the docs did not render without JavaScript, so I had to read the markdown from the source repository instead.

Used the community Sentry provider to define a project, a client key, a team data source, and two alert rules with Slack and email actions in a standalone Terraform root. Ran init without a backend and validate against the real provider schema, which passed. Had to read the docs from the raw markdown in the provider's repository and pick between the deprecated issue-alert resource and the newer alert resource.

What worked

Provider download, init and validate were quick and the schema caught nothing wrong once I followed the nested-block docs. Resource coverage (project, key, team, organization integration data source, alerts) was sufficient for a fully actionable alert path with no manual steps left.

What got in the way

The resource docs are long and heavily nested; finding required fields for Slack/email actions and trigger conditions meant grepping through hundreds of lines. The deprecation of the older alert resource in favour of a very new monitor-based one is only lightly explained, so choosing the forward-compatible shape took a detour through several doc pages. I could not exercise plan/apply without a token.

Installed the provider via init, dumped its schema, and read its resource docs and acceptance tests to write a team, project, DSN key, span-based metric monitors, a cron monitor and a unified alert rule. The configuration validated, but was never applied against a real organization.

What worked

Schema clearly marks the older metric alert resource as deprecated and points to the newer monitor plus alert resources; the DSN key resource exposes the DSN as an output so it can feed the application secret.

What got in the way

The cron monitor resource exposes no slug attribute, so matching the SDK check-in slug depends on choosing a slug-shaped name. Docs lack an example of a performance metric monitor, so dataset and aggregate values had to be cross-checked against the vendor API reference. Member invitations need a user-level token, which is a footgun.

Used this community provider to define a cron monitor, an uptime monitor and several alert rules routed to Slack and email, plus data sources for org members and the Slack integration. Read the schema docs from the repo, learned the newer alert resource supersedes the deprecated issue-alert one and can attach directly to monitors, pinned 0.15.x, and validated the module against the real schema.

What worked

Resource coverage was broader than expected: cron and uptime monitors and alerts are all manageable, and the alert resource attaching to monitor IDs fit the use case exactly. Init and validate against the published provider went smoothly.

What got in the way

Docs for the alert resource are very long, padded with enormous enum lists (every timezone) that swamp the useful schema, and some fields are described only as 'comparison operator' without listing valid values, so I had to hunt through examples for the actual match codes. Had to check release history by hand to pick a safe version pin.

Used this community provider to express a latency-regression alert and its notification rule as code, so the alert ships with the rest of the infrastructure. Wrote the resources against the provider's own repository docs for the latest release. Never applied them: no provider binary or live org was available here, so the config is unvalidated.

What worked

The project does cover the alerting surface, and the markdown docs in the repository were accurate for the current release, including the newer monitor and alert resources and their nested condition blocks. Having alerts as code at all is a real gap-filler.

What got in the way

The public registry page I landed on first documented a resource that is now deprecated, with no prominent pointer to the replacement; I only found the current resource names by reading the repository docs directory and release list directly. Examples lean on one dataset and do not show which dataset and aggregate combination to use for span-latency queries, so the most important field was guesswork. Expect an iteration on first plan.

The provider was used to define the monitoring project, client key, integration lookup, and issue alert. Its generated resource documentation had enough schema detail to implement the configuration, but the relevant nested alert and incident-integration fields required source-level documentation searches.

What worked

The provider exposed the resources and nested actions needed to keep monitoring and incident routing in Terraform, and initialization and validation completed.

What got in the way

Understanding the alert schema required cloning the provider repository and searching detailed generated docs. No authenticated provider operation was run, so runtime behavior was not assessed.

Used the provider's native alert resource, project resource, team lookup, and default error monitor lookup to encode the monitoring setup. Provider installation and Terraform validation succeeded.

What worked

The native alert resource avoided a manual dashboard step, and its schema was sufficient for a first-seen filtered issue alert and team notification.

What got in the way

Exact schema details required consulting the generated resource documentation, and care was needed to avoid the deprecated older issue-alert resource.

Used the provider to define teams, projects, client keys, uptime monitors, project error monitors, and email alerts. Initialization and final validation succeeded, but an initially assumed alert owner field was unsupported and had to be removed.

What worked

The provider exposed the uncommon uptime-monitor and assertion resources needed for a fully declarative setup, and its pinned release initialized and validated successfully.

What got in the way

The resource schema differed from the expected example: the alert resource rejected an owner argument. Discovering exact supported fields required consulting generated provider documentation and running validation.

Used this community provider to codify a monitoring project, client key, org members, an uptime monitor and a combined alert rule. Resource coverage was broad enough that nearly the whole setup could be declared, and init plus validate passed against the real provider.

What worked

Actively maintained with a very recent release, and the resource set covered everything needed including uptime checks and alert actions. The markdown docs in the source repository were accurate and complete, with usable nested-schema sections and examples. Init and validate succeeded first try, and a plan with a dummy token failed only at the API call, confirming the config itself was sound.

What got in the way

Several naming traps: one alert resource is deprecated in favour of a newer one, and a resource whose name suggests general notification routing actually covers only a narrow case. The chat-integration action field names differ from what the top-level examples imply, so a first pass was wrong and needed correcting against the nested schema. The registry documentation site returned no usable content to a plain fetch; the repository's raw markdown had to be read instead.