Sentry to Snowflake: How to Move Your Data

Moving Sentry into Snowflake keeps error history that Sentry itself discards. Events are retained for 30 or 90 days depending on your plan, so any question about whether reliability improved across a year is unanswerable from the platform and easy from a warehouse.

This guide covers the managed path with Airbyte. Two things shape the build: a breaking change in the connector's history changes what the projects stream contains, and error payloads carry whatever your application happened to be holding when it failed.

Sentry to Snowflake at a glance:

Why move data from Sentry to Snowflake?

Two situations account for most of these pipelines.

The first is retention, since a 30 or 90 day window makes quarterly comparison impossible and the value of a warehouse copy compounds the longer it has been running. The second is joining errors to deployments, support tickets and releases, none of which Sentry has ever seen.

Snowflake earns its place here over a plain warehouse copy mainly through access controls, which matter because error payloads are less sanitised than people assume. If what you want is to search error text rather than aggregate it, Sentry to Elasticsearch suits that better.

What do you need before you start?

Four things, and the second decides whether this is a build or a migration:

An auth token with three read scopes. Organisation read, project read and event read together cover every stream. A missing scope returns a 403 on the affected stream rather than failing quietly. The Sentry source documentation covers the scopes and the streams.

Clarity about which connector version you are on. Version 1.0.0 changed the projects stream in ways that matter, and the migration guide flags a risk of data loss for anybody upgrading rather than starting fresh.

Your organisation slug, and your host if self-hosted. Keep the default for Sentry's own service, or supply your hostname without a scheme or path. A wrong slug now fails as a configuration error naming the organisation or project, which is refreshingly specific.

Snowflake objects and a view on who reads error detail. A warehouse, database, schema and a role that can create tables, plus a decision about the payloads discussed below.

If your Snowflake account restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the network policy before you begin.

How do you build a Sentry to Snowflake pipeline in Airbyte?

Step 1: Establish whether you are upgrading or starting fresh

A new pipeline simply gets the current behaviour and needs no thought. An existing one crossing version 1.0.0 is a migration with a documented data loss risk, and reading the migration guide first is considerably cheaper than discovering afterwards that a stream now contains less than it did. Grant all three scopes at once while you are here, since granting them incrementally only extends the debugging.

Step 2: Configure the Sentry source

Click Sources in the left navigation, then New Source, and select Sentry, following adding a source. Supply the auth token, organisation slug and hostname. Select streams knowing that the detailed project stream makes one request per project, which is fine for a handful and noticeable across a hundred.

Step 3: Configure the Snowflake destination

Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role. Event records carry deeply nested context and Snowflake holds that natively, so nothing needs flattening on the way in.

Step 4: Create the connection and sync inside the retention window

Click Connections, then New connection, select your streams and a sync mode. Keep the schedule comfortably inside 30 days, alert on failure, and reduce the number of concurrent workers if you start seeing 429 responses, since rate limits vary by endpoint and are reported in the response headers.

Then apply access controls before telling anybody the schema exists, for reasons the second half of this guide explains.

What changed in version 1.0.0?

The projects stream moved to an organisation-scoped endpoint, because Sentry deprecated the legacy one. Two things follow. The stream now returns only projects belonging to the organisation you configured, which is narrower than before, and several fields it used to carry now come back empty.

Specifically, avatar, colour, the internal and public flags, the organisation reference and status all return null in that stream now. They are still available, but from the detailed project stream rather than the list one, which is the connector's way of separating a cheap listing from an expensive enrichment.

That enrichment has a cost worth knowing: the detailed stream makes one request per project returned by the organisation listing. On a small organisation that is nothing. On one with a hundred projects it is a hundred requests every sync, against limits that vary by endpoint. Sync it if you need those fields and leave it out if you do not, rather than selecting everything by default.

What is actually inside an error payload?

Whatever your application was holding when it failed, which is rather more than most teams expect. Sentry events carry stack traces, request context, user identifiers and any custom context your code attached, and none of that was curated for a warehouse audience. It was captured to help somebody debug at two in the morning.

In practice that means email addresses in request parameters, user identifiers attached for triage, and occasionally values from a form somebody was submitting when the error occurred. In Sentry those sit behind a login and a role. In a warehouse they become ordinary columns any analyst with schema access can select, and nobody intended that.

So look at real payloads before granting access, then mask the identifying parts, since counting errors by type and measuring trends needs none of them. Keep the nested context as semi-structured rather than flattening it, and use TRY_CAST when extracting values, because what applications attach varies by team and a plain cast will stop a query dead on the one service that sent a number as text.

Frequently asked questions

Why are fields in my projects stream suddenly null?

Version 1.0.0 moved that stream to an org-scoped endpoint, and avatar, colour, the internal and public flags, organisation and status now come from the detailed project stream instead.

A stream returns 403. What is wrong?

The token is missing that stream's scope. Grant organisation read, project read and event read together, which covers everything.

Why is the detailed project stream slow?

It makes one request per project in the organisation. That scales linearly with your project count, so select it only if you need the fields it adds.

I am getting 429 responses.

Reduce the number of concurrent workers. Limits vary by endpoint and are reported in the response headers, so this is a tuning exercise rather than a fault.

Can I do this without writing code?

The pipeline, yes. Masking policies and the views extracting event context safely are SQL, and given what payloads contain they are worth writing.

Get your Sentry data into Snowflake

Grant all three scopes at once, and if you are upgrading across version 1.0.0, read the migration guide first because the projects stream changed and data loss is flagged. Select the detailed project stream only if you need the fields it restores, since it costs one request per project. Then look at real error payloads before granting anybody access, mask what your applications attached without thinking, and start collecting early because Sentry keeps 30 or 90 days.

Airbyte's connector catalog includes 600+ pre-built connectors, so error history can outlive the platform's retention window. For the same source into another warehouse, see Sentry to BigQuery, and for observability data into the same destination, Datadog to Snowflake.

Start syncing now →