> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nekt.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Sentry as a data source
> Bring your application error monitoring data from Sentry to Nekt.
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](https://app.nekt.ai/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.
3. 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.
2. 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](https://docs.nekt.com/get-started/core-concepts/catalog-layers) 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](https://docs.nekt.com/get-started/core-concepts/types-of-sync).
2. 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](https://docs.nekt.com/runs/scheduling-and-triggers), 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](https://docs.nekt.com/get-started/core-concepts/resource-control).
* Determine when to execute an **Additional [Full Sync](https://docs.nekt.com/get-started/core-concepts/types-of-sync#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](https://app.nekt.ai/sources) page. Now, for you to be able to see it on your [Catalog](https://app.nekt.ai/catalog), you have to wait for the pipeline to run. You can now monitor it on the [Sources](https://app.nekt.ai/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
| Stream | Sync | Description |
| --------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `issues` | INCREMENTAL | Errors grouped by Sentry into issues, one row per issue per project: title, culprit, level, triage status and substatus, priority, assignee, suggested owners, first and last seen, total event and affected-user counts, and links to tickets in connected issue trackers. Synced per project and re-emitted whenever Sentry sees the issue again. |
| `events` | INCREMENTAL | Individual error events — one row per occurrence — with the event and group ids, message, title, culprit, platform, affected user, tags and metadata. With **Include full event bodies** on, also the stack frames, breadcrumbs, HTTP request, device and runtime context, SDK, loaded packages and processing errors. |
| `user_feedback` | FULL\_TABLE | Feedback submitted by your end users through Sentry's feedback widget, with the message, the reporter's name and email, and the event and issue it was attached to. |
| Stream | Sync | Description |
| -------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `releases` | FULL\_TABLE | Releases registered for the organization: version, status, creation and release dates, the number of issues that first appeared in the release (`new_groups`), commit and deploy counts, first and last event seen, adoption stage per project, and the parsed version info. |
| `release_deploys` | FULL\_TABLE | Deploys recorded against each release, with the environment, start and finish times and a link to your own deployment system. Releases that report no deploys are skipped. |
| `repositories` | FULL\_TABLE | Source repositories connected to Sentry, with their provider, connection status and the integration that owns them. |
| `repository_commits` | INCREMENTAL | Commits Sentry has indexed for each connected repository, with the message, author, the pull request they were merged through, and whether Sentry flagged the commit as a suspect for an issue. |
| Stream | Sync | Description |
| ------------------ | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `monitors` | FULL\_TABLE | Cron monitors: the schedule and its tolerances (cron expression or interval, timezone, check-in margin, maximum runtime, failure and recovery thresholds), mute state, owner, and the per-environment state including the last and next expected check-in. |
| `monitor_checkins` | INCREMENTAL | One row per scheduled run of each monitor, with its outcome (ok, error, missed, timeout, in progress), duration, the time the schedule expected it, and any issue Sentry opened from it. |
| `alert_rules` | FULL\_TABLE | Alert rules and automation workflows, with their triggers and action filters, the environment they watch, whether they are enabled, and when they last fired — the quickest way to find rules that are configured but dormant. |
| Stream | Sync | Description |
| --------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `replays` | INCREMENTAL | Recorded user sessions with their start and finish times, duration, activity score, the pages visited, the browser, operating system and device, the end user behind the session, and the counts that matter for frustration analysis — errors, warnings, dead clicks and rage clicks. Also carries the trace and event ids, so a replay can be joined back to `events`. |
| Stream | Sync | Description |
| ------------------------ | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `projects` | FULL\_TABLE | Projects in the organization, with their slug, platform, creation date, environments, owning teams, latest release and per-environment latest deploys, plus the flags saying which Sentry products the project actually reports data for. |
| `teams` | FULL\_TABLE | Teams defined in the organization, with their member count and the projects they have access to. |
| `team_members` | FULL\_TABLE | Membership of each team, with the role held on that team. |
| `organization_members` | FULL\_TABLE | Everyone in the organization, including pending invitations, with their organization role, invitation status and single sign-on provisioning flags. |
| `environments` | FULL\_TABLE | Environments reported across the organization's projects. |
| `integrations` | FULL\_TABLE | Third-party integrations installed on the organization — GitHub, Slack, Jira and others — with their status, connected account and permissions. |
| `dashboards` | FULL\_TABLE | Custom dashboards, with their widgets' display types, saved filters, edit permissions and when they were last opened. |
| `discover_saved_queries` | FULL\_TABLE | Saved Discover queries: the search expression, the columns and aggregations they return, the dataset they read and when they were last run. |