Skip to main content
Back to Integrations
Sentry logo

Sentry

Inventory Sentry members, their roles, two-factor and SSO status and last activity, teams and who is on them, projects and their client keys, every outside service and app connected to Sentry with the permissions it holds, where error data is sent outside Sentry by webhooks and data forwarding, the organization's security settings, and the audit log of who changed what.

Questions you can answer 18

Each one is a saved query that ships with ConfigView, reading your Sentry data on your own server. Ask it in plain English, SQL, Slack or the API.

  • What is connected to Sentry?
  • Which apps can change data in Sentry?
  • Which GitHub, Slack and Jira accounts is Sentry connected to?
  • Who changed Sentry members or roles in the last 30 days?
  • Which integrations or apps were added to Sentry this month?
  • Show recent Sentry access changes from the audit log
  • Where does Sentry send our error data?
  • Which webhooks receive Sentry errors?
  • Is Sentry forwarding events to Splunk or Segment?
  • Which Sentry members do not have two-factor sign-in?

What ConfigView collects from Sentry 11

  • Installed Apps

    Apps installed on the Sentry organization through Sentry's integration platform, including internal integrations your own team built: who made each one, what it may read or change in Sentry, and the host its webhooks go to. Tokens and secrets are never stored.

  • Audit Log

    Who changed what in Sentry: members invited, removed or given a new role, integrations and apps added or removed, projects and teams created or deleted, settings changed - with the time, the person or app that did it and the IP address. Kept as a growing history. Needs the token's Organization permission set to Read & Write.

  • Data Forwarding

    Where Sentry copies error data outside itself through Data Forwarding - Amazon SQS, Segment or Splunk: the provider, whether it is on, which projects are included and the host, queue region or bucket it sends to. Access keys and tokens are never stored.

  • Integrations

    Outside services connected to Sentry - GitHub, GitLab, Slack, Jira, PagerDuty, Microsoft Teams, Vercel and others: the account each one is connected to, its status and the permissions it was granted. No credentials are stored.

  • Members

    Everyone in the Sentry organization and every open invitation: email, organization role (owner, manager, admin, member, billing), whether two-factor sign-in is on, whether the account is linked to SSO or provisioned by the identity provider, who invited them, and when they last signed in and were last active.

  • Organization Settings

    The Sentry organization's security settings: whether two-factor sign-in and SSO are required, open team membership, the default role for new members, who may invite people or create projects, data scrubbing, and which region the data is stored in.

  • Client Keys (DSNs)

    The client keys (DSNs) apps use to send errors to each Sentry project: key name, project, whether it is active and its rate limit. Only the key's public ID is stored, never its secret or the DSN.

  • Projects

    Sentry projects: name, platform, the teams that own each one, when it was created and when it first received an error.

  • Service Hooks

    Webhooks set on Sentry projects that send every new error or alert to an outside address: the project, which events are sent, and the host they go to. The full URL and signing secret are not stored.

  • Team Members

    Who is on each Sentry team and whether they are a team admin or a contributor.

  • Teams

    Sentry teams: name, how many members each has, the projects it owns, and whether the identity provider manages it.