Sentry

Error tracking; Atrium groups map to Sentry teams.

Capability: observability · Observability. This is a generic capability: every enabled instance receives the same one-way pushes, so several can be connected side by side.

Vendor site · Vendor docs

Configure Sentry in Atrium → (admins only)

Setup

The org-level auth token Atrium uses to provision Sentry teams + projects for dev groups and manage org membership. Self-hosted or sentry.io — point at your host.

Note your Sentry host + org slug. Host is your Sentry base URL (e.g. https://sentry.ommax-intelligence.de or https://sentry.io). Org slug is the short name in your org URL.
Create an org auth token. Sentry → Settings → Auth Tokens (or Organization → Developer Settings → internal integration). Grant org read+write, team write, project write, member read. Copy it once.
Paste host, org slug + token below. Atrium stores the token encrypted (AES-256-GCM) and uses it only server-side to converge Sentry teams from group membership.

What you paste back into Atrium

In order, the values the steps above produce:

Sentry host URL
Org slug
Auth token

How it works

Atrium projects its group model onto Sentry: a dev group becomes a Sentry team, and the people in that group become that team's members. The point is that nobody hands out Sentry access by hand, and access disappears when group membership does. Works against self-hosted Sentry or sentry.io; the host field is what picks.

What Atrium does, and when

When this happens	Atrium does this
A dev group is wired to observability	Creates the corresponding Sentry team under the configured org, and its project when one is expected.
Someone joins that group	Adds them to the Sentry team, inviting them into the org first if they are not a member yet.
Someone leaves	Removes them from the team. Org membership itself is left alone, because it may be justified by another team.

Guarantees and limits

Observability is a generic capability: every enabled instance receives the same one-way push, so two Sentry orgs can be connected side by side without one disabling the other.
The documented scopes (org read and write, team write, project write, member read) are the least-privilege set. Member read rather than member write is deliberate: Atrium reads who exists, and manages team membership, not org-level user administration.
The auth token is encrypted at rest (AES-256-GCM) and never returned to the browser.

What "Test connection" proves

Reads the organization detail endpoint on the configured host with the token. A pass proves the host, org slug and token triple are valid and the token can read the org. It does not prove the write scopes are present, so a read-only token passes here and fails on the first team creation.

Troubleshooting

Symptom	Cause	Fix
Test connection returns 404.	The org slug is wrong for this host. The slug is the short name in the org URL, not the display name.	Copy the slug straight out of your Sentry URL.
Test passes, creating a team fails with a permission error.	The token has read scopes only.	Re-issue the token with team write and project write, then paste the new one.
Sentry shows no events, and the team looks unused.	Provisioning a team says nothing about whether an application is actually reporting to it. Silence is ambiguous.	Verify separately that the application has a matching DSN and captures on its failure path. An empty project is not evidence of a healthy one.

Required scopes

Grant the credential exactly these scopes; they are the least-privilege set the connector needs:

org:read
org:write
team:write
project:write
member:read

Configuration fields

Field	Type	Required	Notes
`host` Sentry host	`text`	yes	Base URL of the Sentry instance. Maps to SENTRY_HOST. e.g. `https://sentry.ommax-intelligence.de`
`org` Org slug	`text`	yes	The organization slug. Maps to SENTRY_ORG. e.g. `sentry`
`authToken` Auth token	`password` secret	yes	Org auth token with org/team/project write + member read. Maps to SENTRY_AUTH_TOKEN. e.g. `sntrys_…`

Operating notes

Secret fields are encrypted at rest (AES-256-GCM) and never returned to the client. Editing an instance and leaving a secret field masked keeps the stored value.
Adding a connector from the marketplace creates a disabled, credential-less instance ("Added, not yet connected"); it does nothing until an admin opens it, pastes credentials, and enables it.
Use Test connection on the instance page before enabling: it performs a read-only probe with the credentials you entered.
Connector credentials live in the Atrium database, not in container env vars; changing them here takes effect without a redeploy (within the resolver's 30-second cache).