Sentry

Sentry alerts open incidents in Ace, and Ace reads the errors behind them while it investigates. Repeated events of one Sentry issue land in the same incident, so a noisy error doesn't open a new incident each time it fires.

What Ace readsCopy Anchor Link

Ace reads Sentry while it investigates a workload that lists Sentry under Investigation sources or routes its alerts. Every read covers the incident window and stays inside your project allowlist, if you set one.

• Unresolved issues in the window, most frequent first.
• The latest event of an issue. Ace gets exception types and messages, in-app stack frames, the release, and only these tags: environment, release, transaction, url, server_name and runtime.
• Recent releases, with dates and the number of new issues each one introduced.
• Explore table and aggregate queries over errors, spans and logs.
• Session replays with errors. Replays carry user identity, so Ace gets only the pages visited (without query strings), environment, browser, OS and error IDs.
• New events of the incident's issue after a fix, to confirm the errors stopped.

Ace also adds your Sentry projects to the System Map.

What Ace can changeCopy Anchor Link

These writes change what your team sees in Sentry and never touch code or infrastructure. They need extra token permissions and run only after an admin turns on Allow Ace to update this tool during incidents for the connection, and from then on they run without an approval step.

Ace skips issues outside your project allowlist, and it leaves an issue alone if someone changed its status in the meantime, so it doesn't overwrite your team's triage. You undo each change from the incident. See Actions and approvals for how actions work in general.

What opens an incidentCopy Anchor Link

Sentry alerts open incidents only on workloads that route this connection (Integration alerts on, Sentry selected). Ace drops alerts that no workload routes.

Ace ignores every other delivery, such as issue assignments.

Ace also polls Sentry for new unresolved issues at level error or fatal, so a missed webhook doesn't hide a new failure. Polling never opens incidents for warnings, info or user feedback.

Before you startCopy Anchor Link

• The admin role in Ace.
• The Manager or Owner role in your Sentry organization, to create an internal integration. Organization auth tokens can't read events, so use an internal integration.

Credentials and permissionsCopy Anchor Link

Both credentials come from one Sentry internal integration. Leave every permission not listed here at No Access.

Set upCopy Anchor Link

1. Create the internal integration in SentryCopy Anchor Link

1. Go to Settings > Custom Integrations > Create New Integration > Internal Integration.
2. Name it Ace. Under Permissions, set Project: Read, Release: Admin, Issue & Event: Read and Organization: Read. For issue updates, set Issue & Event: Read & Write and Member: Read instead.
3. Select Save Changes, then copy the token under Tokens and the Client Secret under Credentials right away. Sentry shows the client secret only briefly after creation, and Rotate client secret issues a new one later.

2. Connect Sentry in AceCopy Anchor Link

1. Open Settings > Data sources and choose Sentry.

2. Fill in the form:

   Field	What to enter
   Auth token	The token from the internal integration.
   Organization slug	Your Sentry organization slug.
   Sentry URL	Optional. https://de.sentry.io for organizations hosted in the EU, or your self-hosted URL. Leave blank for https://sentry.io.
   Projects	Optional. A comma-separated allowlist of project slugs.
   Client secret	Optional. The client secret from the same integration. Ace needs it to verify alert webhooks.

3. Select Connect Sentry. Ace checks the token before it saves.

A self-hosted Sentry URL must use HTTPS and be reachable from the public internet, because Ace doesn't connect to private or internal network addresses.

3. Send alerts to AceCopy Anchor Link

1. In the Alerts section, copy the webhook URL.
2. In Sentry, open the internal integration and paste it as the Webhook URL.
3. Turn on Alert Rule Action, subscribe to issue, and save.
4. In Monitors > Alerts, open or create each alert that should open incidents. Under Then, add the Ace integration.

4. Route alerts to a workloadCopy Anchor Link

Open the workload in Ace, turn on Integration alerts, and select Sentry as a source.

5. Optional: allow issue updatesCopy Anchor Link

If the token has the write permissions, turn on Allow Ace to update this tool during incidents on the connection.

Confirm it's workingCopy Anchor Link

• The connection's checks read the organization and report how many projects the token sees. If the token can't see a project in your allowlist, the check names it.
• The Alerts badge shows Not set up, Waiting for first event, Verified or Last delivery failed. Send a test alert from Sentry, and the badge turns Verified when the first signed delivery arrives.
• A failed delivery shows the reason, such as a signature that doesn't match the saved client secret.
• Re-validate reruns the checks.

DisconnectCopy Anchor Link

1. In Ace, open the Sentry connection under Settings > Data sources and select Disconnect. To stop issue updates and keep the connection, turn off Allow Ace to update this tool during incidents instead.
2. In Sentry, delete the Ace internal integration or its token. Ace creates nothing else in Sentry.

Next stepsCopy Anchor Link

• How Ace works
• Actions and approvals
• All integrations