Sentry

Sentry is a read-only signal source. Unresolved Sentry issues arrive in nima as evidence, so what is breaking in production competes for the roadmap next to what people ask for. Each signal links back to its issue.

Connect Sentry

A workspace owner or admin connects Sentry from Integrations in the nima app: click the + button on the Sentry tile (its label is Connect Sentry) and approve the access on Sentry's authorization screen. You return to nima and the first sync starts straight away.

• Sign-in flow. nima uses OAuth 2 with PKCE and no client secret. Access renews itself with refresh tokens.
• Scopes. org:read (which Sentry organizations the account belongs to), project:read (project name and platform) and event:read (issues and their latest event, including stack frames). Nothing is written to Sentry.
• Which organizations. The token belongs to the person who authorized it. nima reads every Sentry organization that person belongs to and refreshes the list on each sync. Choosing organizations or projects is not available.
• Sentry SaaS only. sentry.io and its regional hosts work. Self-hosted Sentry does not.
• If connecting fails. You return to Integrations with an error when the Sentry account belongs to no organization nima can read, or when Sentry does not return a refresh token. Reconnect with an account that is a member of the organization.
• If access fails for good. When Sentry rejects the stored refresh token, the Sentry tile reads Needs reconnect and offers Reconnect, and syncing stops until you reconnect.

The Integrations page has no Sync now button for Sentry, and the enable switch only changes the card's label to Paused. It does not stop new signals. A signed-in owner or admin session can queue an immediate sync with POST /v1/sentry/app/sync (answers 202) and read the connection with GET /v1/sentry/app/status (connected Sentry organizations, last sync time, whether the connection is invalid).

What arrives from Sentry

nima creates one signal for each unresolved Sentry issue. Sentry groups the occurrences, and nima inherits that grouping.

• Content. Issue title, culprit, project and platform, event count and affected users, first and last seen, Sentry level, exception type and value, and a permalink to the issue. The signal's channel is sentry:<org>/<project>.
• Redaction. nima strips secrets, emails, phone numbers and URL query strings from the text before it is stored, and caps it at 8,000 characters.
• Re-seen issues. Each sync asks only for issues first seen since the previous run (with a 5-minute overlap). When an overlapping sync sees the same issue again, nima does not create a second signal; it merges the new evidence into the existing signal in place, and never reopens shipped work or overwrites PM content. The signal text and its event and user counts stay as they were when the issue was first pulled. Only the incident evidence (state, counts, last occurrence) is refreshed when an overlapping sync sees the issue again. get_signal_source reads the issue as it stands now.
• Incident evidence. Each signal carries bug-incident evidence: state open while the issue is unresolved, severity taken from the Sentry level, affected and occurrence counts, and one top stack frame.
• Weight. Sentry signals are internal and carry a producer weight of 0.8 when a beacon is ranked. A default source weighs 0.5.
• The original issue. get_signal_source re-reads the issue live from Sentry, with its latest event and top frames. It needs a workspace owner or admin.

A resolved issue that returns produces no new signal. There is no severity or event-count floor, so every new unresolved issue costs an extraction pass.

Sentry sync timing and limits

nima syncs Sentry every 10 minutes and once immediately after you connect.

If a Sentry organization answers 403 (for example SSO enforcement or a grant without event:read) or 429 (rate limited), nima skips it, logs a warning and retries it on the next run. The other organizations still sync. A run that hits the 500-issue cap in any Sentry organization, or skips one, keeps its sync position, so the next run searches the same window again from the newest issue. Each run reads at most the 500 newest unresolved issues in that window. When more than 500 are unresolved, the older ones are not read until enough of the newer ones are resolved. Issues read again are not duplicated. A run that sees no organizations at all does not advance the sync position.

Disconnect Sentry

Disconnect from the Sentry card on Integrations. nima deletes its stored connection and stops reading. Sentry has no token revoke endpoint, so also remove nima from your Sentry account's authorized applications.

Signals already created stay, with their links. nima can no longer re-fetch the original issues.