Sentry User Management Guide

• Model type: role-based
• Description: Sentry uses a two-level role system: organization-level roles (Billing, Member, Admin, Manager, Owner) and team-level roles (Contributor, Team Admin). Organization roles control what a user can do across the org; team roles control what they can do within a specific team. Project access is gated by team membership.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Organization-level roles are fixed and cannot be customized. Team-level roles (Contributor vs. Team Admin) provide a secondary layer of access control within teams. No attribute-level or resource-level permission customization is available.

1. Navigate to Settings → Members in the Sentry organization dashboard.
2. Click 'Invite Members'.
3. Enter the email address(es) of the user(s) to invite.
4. Select the organization-level role to assign (Billing, Member, Admin, Manager, or Owner).
5. Optionally assign the invitee to one or more teams.
6. Click 'Send Invite'. The invitee receives an email with an invitation link.
7. The user accepts the invite and creates or logs into their Sentry account.

Required fields: Email address, Organization role

Watch out for:

• Only Owners and Managers can invite new members by default. Admins can invite members only if the organization setting 'Let Admins invite new members' is enabled.
• Invitations expire after 48 hours if not accepted.
• If SSO is enforced, invited users must authenticate via SSO on first login; email/password login is blocked.
• JIT (Just-in-Time) provisioning via SSO creates a user account on first SSO login without a prior invitation, but the user is assigned the default Member role unless SCIM is used to pre-assign roles.
• Inviting a user to a team at invite time is optional; team membership can be managed separately after the user joins.

• Can delete users: Yes
• Delete/deactivate behavior: Sentry allows removing (revoking) a member from the organization. This removes their access entirely. There is no 'deactivate' or 'suspend' state in the Sentry UI - removal is the only option for revoking access manually. When SCIM is enabled, deprovisioning via the IdP removes the user from the Sentry organization. Removed users' Sentry accounts still exist but they lose all access to the organization.

1. Navigate to Settings → Members.
2. Locate the member to remove using the search field.
3. Click the three-dot menu (⋮) or 'Remove' button next to the member's name.
4. Confirm the removal in the dialog prompt.
5. The member is immediately removed from the organization and loses all access.

Watch out for:

• Only Owners and Managers can remove members. Admins cannot remove members from the organization.
• If the organization has SSO enforced, removing a user from Sentry does not automatically deprovision them in the IdP. The IdP must also be updated to prevent re-provisioning on next login.
• If SCIM is configured, deprovisioning should be done via the IdP to ensure consistent state; manual removal in Sentry UI and IdP deprovisioning should not conflict but dual-management can cause sync issues.
• The last Owner cannot be removed. At least one Owner must remain in the organization at all times.
• Removed users can be re-invited; their historical data (issues, comments) remains associated with their account.

• Where to check usage: Settings → Members (shows current member count and roles). Billing details at Settings → Billing.
• How to identify unused seats: Sentry does not provide a native 'last login' or 'inactive member' report in the UI as of early 2025. Admins must manually review member lists or use the Sentry API endpoint GET /api/0/organizations/{organization_slug}/members/ to audit membership. SCIM-enabled organizations can cross-reference IdP activity logs.
• Billing notes: Sentry's billing model is primarily based on event volume (errors, transactions, replays, etc.), not per-seat fees. All plan tiers allow unlimited members on paid plans, though the Developer (free) plan is limited to 1 user. Business plan ($89/mo base) is required for SSO and SCIM. Enterprise pricing is custom and includes 90-day data retention and advanced features. Non-profit and academic discounts are available upon request.

Sentry's pricing is primarily event-volume-based, not per-seat, so adding members does not trigger a direct per-user line item on paid plans. The Developer plan is capped at one user; all paid tiers (Team at $29/mo base, Business at $89/mo base) allow unlimited members.

SCIM and SAML SSO - the tools that make provisioning scalable - are gated behind the Business or Enterprise plan. Without them, every app that onboards engineers requires manual invitations, manual role assignments, and manual removal when staff leave.

Practitioners consistently flag four friction points. First, Google Workspace SCIM does not support group-based role assignment, so roles must still be set manually in Sentry after provisioning.

Second, the Owner role cannot be assigned or managed via SCIM at all - ownership changes always require UI intervention. Third, there is no native inactive-user or last-login report in the Sentry UI, making seat audits dependent on the REST API or IdP activity logs.

Fourth, invitation links expire after 48 hours, creating re-work when invitees are slow to respond.

Common complaints:

• Google Workspace SCIM integration does not support group-based role assignment, requiring manual role management in Sentry after provisioning.
• The Owner role cannot be assigned or managed via SCIM, forcing manual intervention for ownership changes.
• SCIM and SAML SSO require the Business or Enterprise plan, making automated provisioning unavailable on the free Developer or Team plans.
• No native inactive-user report or last-login visibility in the Sentry UI makes it difficult to audit and reclaim unused seats.
• Invitation links expire after 48 hours, causing friction when invitees do not act promptly.
• Admins (as opposed to Managers/Owners) have limited ability to manage members by default, requiring an explicit org-level setting change to allow Admin-initiated invites.
• Removing a user from Sentry does not automatically revoke their IdP session or deprovision them in the IdP, requiring dual management when SSO is enforced without SCIM.

Manual management is workable for small, stable teams where member turnover is low and the organization has not yet reached the Business plan threshold.

It becomes a liability at scale: Admins cannot remove members by default (only Owners and Managers can), SSO enforcement blocks email-based login without a corresponding IdP update, and removing a user in Sentry does not deprovision them in the IdP - leaving re-provisioning risk on the next SSO login.

Every app in the IdP that pushes group membership to Sentry reduces the manual surface area and closes the offboarding gap that manual removal alone cannot address. Teams with regular onboarding and offboarding cycles should treat SCIM via the IdP as the authoritative provisioning path, not the Sentry UI.

Bottom line

Sentry's manual member management is straightforward for small teams but accumulates operational debt quickly as headcount grows. The absence of a last-login report, the 48-hour invite expiry, and the Owner-only SCIM blind spot each require compensating processes.

Organizations that have reached the Business plan and configured SAML SSO should enable SCIM immediately - every app in the IdP that pushes group membership to Sentry reduces the manual surface area and closes the offboarding gap that manual removal alone cannot address.