Skip to main content
Sentry is an application monitoring platform that captures the errors, crashes and performance problems your software hits in production. This connector extracts your Sentry organization: the errors grouped into issues and the individual events behind them, the releases and deploys they can be attributed to, cron monitors with their check-ins, session replays and user feedback, plus the structure around it all — projects, teams, members, environments, connected repositories, dashboards, saved queries and alert rules.

​
1. Add your Sentry access

  1. In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Sentry option from the list of connectors.
  2. Click Next and you’ll be prompted to add your access.
    • Auth token: required. In Sentry, go to Settings > Auth Tokens and click Create New Token. This creates an organization token, which is the right choice for a pipeline because it is not tied to any one person and does not stop working when they leave. Give it read access to everything the connector reads: org:read, project:read, project:releases, event:read, member:read, team:read, alerts:read and org:integrations. Copy the token immediately — Sentry does not show it again after you close the dialog.
    • Organization slug: required. The short name of your organization, exactly as it appears in the Sentry address bar. In https://acme.sentry.io/issues/ the slug is acme. You can also read it under Settings > General Settings > Name.
    • Initial sync date (advanced): earliest date to sync for the incremental streams. Leave empty to start from the oldest data Sentry still serves.
    • Sentry host (advanced): keep sentry.io for Sentry’s cloud service. If your organization’s data is stored outside the United States, enter your region address instead — de.sentry.io, for example — which you can confirm under Settings > General Settings. For a self-hosted Sentry, enter your own address, such as sentry.mycompany.com.
    • Projects (advanced): limit the per-project streams to a few project slugs. Leave empty to read every project.
    • Include full event bodies (advanced): brings stack traces, breadcrumbs and request context into the events table. Off by default.
    • Maximum history (days) (advanced): how far back the events stream may ask Sentry for data. 90 by default.
A personal token, created under User settings > User Auth Tokens, also works — but it only reaches what that specific user can see, and it stops working when their account is deactivated. Prefer an organization token.
  1. Click Next.

​
2. Select your Sentry streams

  1. The next step is letting us know which streams you want to bring. You can select entire groups of streams or only a subset of them.
    Tip: The stream can be found more easily by typing its name.
If your token is missing one of the permissions above, the affected stream is skipped with a message in the run log naming the permission it needed — the rest of the sync still runs. The same happens for a Sentry product your plan does not include: session replays and cron monitors simply come back empty instead of failing the run.
  1. Click Next.

​
3. Configure your Sentry data streams

  1. Customize how you want your data to appear in your catalog. Select a name for each table (which will contain the fetched data) and the type of sync.
  • Layer: companies in the Growth plan can choose in which layer the tables with the extracted data will be placed.
  • Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
  • Sync Type: depending on the data you are bringing to the lake, you can choose between INCREMENTAL and FULL_TABLE. Read more about Sync Types here.
  1. Click Next.

​
4. Configure your Sentry data source

  1. Describe your data source for easy identification within your organization. You can inform things like what data it brings, to which team it belongs, etc.
  2. To define your Trigger, consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times).
  3. Optionally, you can define some additional settings (if available).
  • Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
  • Determine when to execute an Additional Full Sync. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.

​
Check your new source!

  1. Click Next to finalize the setup. Once completed, you’ll receive confirmation that your new source is set up!
  2. You can view your new source on the Sources page. Now, for you to be able to see it on your Catalog, you have to wait for the pipeline to run. You can now monitor it on the Sources page to see its execution and completion. If needed, manually trigger the pipeline by clicking on the refresh icon. Once executed, your new table will appear in the Catalog section.
If you encounter any issues, reach out to us via Slack, and we’ll gladly assist you!

​
Before you rely on the data

Sentry deletes old events. Error events are kept for 30 to 90 days depending on your plan, and session replays for 90 days. Sentry rejects a request that reaches past that window rather than returning what it still has, so the events and replays streams start at the oldest date Sentry still serves — an earlier initial sync date cannot recover data Sentry has already discarded. The aggregated issues rows survive far longer than the individual events behind them, so if you need long-term history, keep syncing regularly and let your warehouse become the archive.
A few behaviours are worth knowing before you build on these tables:
  • issues is a moving picture, not an append-only log. Its replication key is last seen, so an issue that keeps happening is re-synced on every run with its counters updated. That is what keeps count and user_count current.
  • issues.count arrives as text. Sentry serializes that counter as a string, so cast it before doing arithmetic on it.
  • events is by far the largest stream — one row per error occurrence, against one row per group of occurrences in issues. Turning Include full event bodies on multiplies the size again.
  • releases always syncs in full. Sentry’s release endpoint accepts no date filter, so syncing it incrementally would make exactly the same requests while freezing the counters that change after a release is created — new_groups, last_event, deploy_count.
  • Nested data arrives as JSON text. Fields with sub-structure — an issue’s metadata, an event’s tags and contexts, a monitor’s config — are stored as JSON strings. Read them with JSON_VALUE(column, '$.field') in your queries.
  • Client keys and DSNs are not extracted. That endpoint returns secret key material, which has no place in a warehouse table.

​
Available streams