What you can export from Sentry before leaving
A renewal, a data residency review or a lock-in assessment is usually the moment a team needs a complete copy of its Sentry data. Issues, events and project settings can generally be pulled out through Sentry's web API, which makes that copy practical for most teams. Alert rules, integrations and other configuration that lives in the Sentry interface are not a reliable part of that export, so they need a separate inventory. Confirm the exact endpoints and response fields against Sentry's current API reference before you write any script, because the API changes over time.
Start by checking which region your organization is hosted in, since Sentry's API is served from region-specific hosts and a request sent to the wrong one will fail or return nothing useful. Create an auth token with the narrowest read scopes that cover the resources you need, and record who owns it so the token can be revoked once the export is complete. Large projects return results in pages linked by cursors, so your script should follow the next-page cursor until none remains rather than assuming a single response is complete. Read the rate limit headers on each response and back off when told to, and plan the export for a window where a long run will not disrupt on-call work.
The export gives you a record of what happened, not a working configuration in GlitchTip. Treat the exported issues and events as an archive for audits, incident reviews and support tickets, and decide with your compliance and security leads how long that archive must be kept and where. Alert rules, notification routing, integrations such as chat or ticketing hooks, and team and member assignments will need to be recreated by hand in GlitchTip, so write them down from the Sentry settings pages before you start. Running both tools in parallel for a short period lets you confirm that new alerts reach the same people before the Sentry subscription ends.
Which Sentry data types export through the web API
This table lists the Sentry data types you can pull out of SaaS through its web API, how each one is read, and what to check before you start. Use the last column to see which items carry over to GlitchTip as data and which you must rebuild by hand.
| Data type | Export through web API | Carry to GlitchTip | Confirm in Sentry's API reference |
|---|---|---|---|
| Issues | Read through the API, one page at a time using cursor pagination | Reference only, since grouped history does not import as-is | Endpoint names, page size and rate limit headers for your plan |
| Events | Read per issue or project through the API, with cursor pagination | Reference only, since events are not replayed into GlitchTip | Whether event payloads include stack traces and attachments |
| Project settings | Read through the API for each project and organization | Recreate by hand as projects and team settings | Which settings the API returns for your organization type |
| Teams and members | Read through the API for organization membership and team assignments | Recreate by hand, then invite users to GlitchTip | Whether member email addresses are returned to your role |
| Alert rules | Read through the API for reference | Recreate by hand, since rules do not transfer | Field names and any alert-rule API limits |
| Integrations | Read through the API for reference | Recreate by hand with the destinations you still use | Which integrations expose configuration through the API |
| Regional API host | Requests go to the host for the region where the organization lives | Not applicable, but determines where you call from | The correct host for your organization's region before you script exports |
| Rate limits | Each response carries headers that show remaining requests and reset time | Not applicable, but affects how long a full export takes | Header names and limits for your plan, and how to back off |
What does not come out of Sentry and how to handle it
The Sentry web API returns issues, events and project settings, but much of the configuration that makes an error tracker useful lives outside those objects. Alert rules, integrations, notification routing, user accounts, SSO and attachments need a separate plan. Each item below names a workaround and the question to put to Sentry before you cut over.
Alert rules and thresholds
Issue alert and metric alert conditions, filters and actions are configuration, not historical data, so they do not form a clean import. Export them by hand from each project's alert pages and record the conditions, environments, frequency limits and recipients in a spreadsheet. Recreate the equivalent rules in GlitchTip, then fire a test error from each environment to confirm the route works. Ask Sentry whether any rule export is available in your plan or API version.
Integrations and webhooks
Slack, Microsoft Teams, Jira, PagerDuty and custom webhook connections hold OAuth tokens or endpoint secrets that the export will not carry across. Inventory every installed integration per organization and project, note the destination channel or ticket project, and reconnect each one in GlitchTip with a fresh credential. Rotate any token that was shared during the old setup. Confirm with Sentry which integration settings can be read back through the API and which must be captured from the UI.
Notification routing and owners
Who receives which alert is usually encoded in ownership rules, team membership and per-user notification settings. These do not map one to one onto GlitchTip teams and projects. Write down the owner for each service before migration, including an on-call rotation or shared mailbox, and map each owner to a GlitchTip team. Check that no alert depends on a personal mailbox that will be deactivated when the old account is closed.
User accounts and memberships
The export gives you project data, not a reliable record of who holds which role. Pull the member list for each organization and team from the Sentry settings pages, then decide which accounts need access to GlitchTip and at what role. Invite users directly rather than expecting them to carry over. Remove departed staff from the list first so you do not recreate stale access in the new tool.
SSO and identity configuration
If your Sentry organization uses SAML or another single sign-on provider, the identity provider settings, attribute mappings and enforcement rules stay in Sentry and do not export. Document the provider, the application registration, the group claims and the enforcement state. Set up authentication in GlitchTip against your identity provider in a test environment first, and confirm with Sentry exactly which login methods your plan and tenant currently allow.
Attachments and session replay
Event attachments and any session replay recordings are heavy, may sit under separate retention settings and are not part of the standard events export. Decide before cutover whether you need them as evidence. If you do, ask Sentry in writing how attachments and replays can be downloaded for your plan and how long they remain available. Keep the historical export in an access-controlled location and document what it contains.
How cursor pagination and rate limits shape the export
The export script has to follow pagination to the end, because a single request returns one page of issues or events and nothing more. Sentry's list endpoints mark the next page with a cursor, and the response indicates whether more results exist. The script should request the next page with the cursor from the previous response, repeat until no further pages are indicated, and only then treat the export as complete. Cursors are opaque strings, so pass them back unchanged and never parse or build them. Save the last cursor after each page is written to disk, so an interrupted run can resume without downloading everything again and without silently skipping a gap.
Rate limits decide how fast the script can run, and the response headers are the only reliable signal of how much headroom remains. Read the rate limit headers on every response and log the remaining allowance, so you can see whether the export is nearing a limit before it fails. When the API returns a throttling status, honor any retry guidance it sends. Where none is given, back off with increasing, jittered delays and retry the same cursor. Retrying a page is safe only if the earlier write was idempotent, so key each stored record on its Sentry ID to avoid duplicates. Confirm the exact header names and the windows that apply to your plan in Sentry's API documentation before you set thresholds.
The region of the organization determines the API host, so the script must call the host that matches its data region. Sentry organizations are created in a specific region, and an export pointed at the wrong regional host will fail or return data you do not expect. Check where the organization lives in its settings, confirm the regional hostname in Sentry's API documentation, and store it as one configuration value shared by every script. Then run a small test export for one project and one date range, and compare the record count with the Sentry interface. The test also shows whether your tokens are valid for that region, which matters for residency reviews.
Export sequence from Sentry to a verified archive
This sequence moves Sentry project settings, issues and events into a checksummed raw JSON archive, with a count check at each stage so the archive can be treated as complete only after reconciliation. It is meant to run before or alongside any move to GlitchTip, so history survives whatever happens to the source account.
Inventory organizations, teams and projects
Start by listing every Sentry organization you can access, then every team and project inside it, with the owner of each. Record the project slug, platform and the region where the organization lives, since API hosts are region-specific and a request sent to the wrong host will fail or return nothing useful. Save the inventory as a dated file in the archive folder. It is done when the inventory lists every project you expect to export, and an administrator has confirmed that no project is missing.
Export project settings and client keys
For each project, pull the project details, team membership, alert and integration configuration through the web API, and store each response unchanged as raw JSON. Settings are the input for re-creating alert rules and integrations by hand in GlitchTip, so treat them as the reference document for that work. Client keys (DSNs) should be recorded as metadata only and handled as secrets. The step is complete when every project has a settings file and a checksum entry.
Page through issues with cursor pagination
Request issues for each project and follow the cursor links in the response headers until no further next page is returned, rather than guessing page numbers. Write each page to its own raw JSON file in order, and log the cursor value used for each request so a failed run can resume from the last recorded page. Confirm that the stored pages add up to the number of issues the response reported. The step is complete when each project has a continuous, gap-free chain of pages.
Export events for each issue
Retrieve the events attached to each issue using the same cursor method, keeping the event payloads complete, including stack traces, tags and contexts. Event volume can be far larger than issue volume, so run this per project in batches and keep a running count of events written per issue. Note any issues that return zero events or an error, because those are the first candidates for a re-run. The step is complete when each issue has a recorded event count and its files are present.
Store raw JSON with checksums
Save every response exactly as received, without reformatting or trimming fields, and generate a SHA-256 checksum for each file. Keep a manifest that lists file path, byte size, checksum, source endpoint and export timestamp. Store the archive in a location with access control and write-once or versioned storage where your environment provides it. The step is verified when a second person can recompute the checksums and get the same values from the stored files.
Handle rate limits and record each retry
Read the rate limit headers returned with each response and pause when the remaining allowance falls to zero, honoring the reset time the response gives. Log every throttled response and every retry with its timestamp and the request it affected, and never discard a failed page silently. Confirm the rate limit values and header names against the current Sentry API documentation before you write the script, because the exact fields may change. The step is verified when the log shows every retried request ending in a successful, stored response.
Check counts against the Sentry UI
For a sample of projects, compare the exported issue and event counts with what the Sentry web interface shows for the same filters and time window. Sample projects of different sizes, including at least one with a high event volume and one with few events, because differences show up in different places. Investigate any mismatch before continuing, and note whether it came from retention limits, filters or pagination. The step is verified when the sampled counts match or each difference has a documented explanation.
Reconcile the full archive before marking it complete
Run a final pass that recomputes every checksum, confirms that each project's stored page and event counts match the totals recorded during export, and checks that the settings inventory covers every project in the first step. Produce a reconciliation report listing any gaps, failed requests and accepted exceptions, with the name of the person who signed it off. The archive is treated as complete only when the report shows no unexplained differences, and only then should the Sentry source be considered for decommissioning.
Questions teams ask before exporting from Sentry
How much effort does exporting from Sentry take?
The effort depends mainly on how many projects you have, how many events and issues each one holds, and how often Sentry's API rate limits slow the pull. Each project is paged through a cursor-based API, so a team with a few projects and modest history has a small job, while a team with many projects and years of events has a larger one. Ask for the export to be estimated per project, with a sample pull run first to measure real throughput against the rate limit headers returned by the API. Get a quote from a written scope rather than a generic estimate.
What does the export need from our team before it starts?
Three things must be in place: an API auth token with read scopes for the organization, projects and events you want to export, a named owner who can approve what is pulled and where it lands, and storage that meets your retention and access rules. The token should be scoped to read access only and revoked after the job. Storage should be encrypted and access-controlled because exported events can contain personal data from error payloads. Confirm these requirements with your own security team before the work begins.
Can our engineers run the Sentry export themselves?
Yes, if they have time, API experience and a clear list of what must be kept. Sentry's web API returns issues, events and project settings, and paging, rate limits and region-specific API hosts all need to be handled correctly. Your team should also plan to re-create alert rules and integrations by hand in GlitchTip, since those are not carried over by an API export. Teams that want the work with a defined outcome can ask DeployOpen for a fixed-scope engagement, which covers planning, implementation, documentation and handover as agreed in writing.
How do we verify that the exported data is complete?
Verification means comparing record counts per project and per issue against Sentry, checking that a sample of events opens with its stack trace, tags and timestamps intact, and confirming that the export log shows no pages skipped or failed. Compare the totals before and after each run, because events keep arriving while you export. Record the checks in a short sign-off document that names who approved the result. The time this takes depends on how many projects and how much history you hold, so ask for the verification steps to be included in the written scope.
What does a fixed-scope outside engagement cover?
A fixed-scope engagement covers the scope, deliverables and timeline agreed in writing before work starts. For an export, that typically means inventorying projects and history, building and running the extraction, setting up secure storage, verifying the output, documenting the process and handing over the results. It does not include changes to Sentry itself, and it is not an audit or certification. Ask for a quote based on your written scope, including which projects, which data types and which GlitchTip setup are in and out.
What is the cost of an export, and what drives it up?
The cost has three parts: the labor to plan, script and verify the export, the storage for exported data, and the ongoing time to keep alert rules and integrations working in GlitchTip. The main drivers are project count, event volume, how much history you must keep, how many integrations need manual re-creation, and how strict your retention and access requirements are. Storage cost is usually small compared with labor. Work out which parts are one-time and which recur, and ask any provider to show these separately in the quote.
Which Sentry data can be exported, and what must be rebuilt by hand?
Issues, events and project settings can be pulled through Sentry's web API, using the region-specific API host for your organization. Alert rules, integrations, notification routing and team membership should be treated as items to re-create by hand in GlitchTip, so plan that step as a checklist. Confirm the current API endpoints and the rate limit headers in Sentry's API documentation before you write any export code, since these details change over time.
What to plan before the Sentry contract ends
Each decision below has a deadline that comes before the contract does, so work backward from the renewal or termination date. Export, parallel running, rebuilding alerts and revoking access depend on one another, and skipping one tends to leave gaps in error history or in on-call coverage.
Set the export start date
Choose the date you begin pulling issues, events and project settings from Sentry, and count back from it. Sentry's API paginates results with cursors and returns rate limit headers, so large projects take longer than a quick script suggests. Start early enough that you can re-run the export for the final days before cancellation.
Plan the parallel run window
Decide how long both Sentry and GlitchTip receive the same errors. Because GlitchTip accepts Sentry client SDKs, you can point a DSN at both during this window and compare grouping and volume. Agree on the criteria that let you stop sending to Sentry, such as matching alert behavior on a set of test errors.
Build the rebuild list
Inventory every alert rule, notification route, integration and issue assignment that lives only in Sentry's settings. The API export covers issues, events and project settings, but alert rules and integrations must be re-created by hand in GlitchTip. Assign an owner to each item so none is lost during cutover.
Decide archive retention
Decide how long the exported archive must be kept, who may read it and where it is stored. Error events can contain personal data or secrets that were not scrubbed at capture, so the archive needs the same access controls and retention rules as production logs. Confirm this with your privacy and records owners before export.
Schedule token revocation
List every Sentry auth token and internal integration that your scripts, CI jobs or SDK configurations use. Plan to revoke them after the final export and after the parallel run ends, not before, because a revoked token stops the export. Record who approved the revocation and when it happened.
Confirm post-cancellation data in writing
Ask Sentry in writing what data remains available after cancellation, how long it is retained and how you can request deletion. Do not assume that stored events, attachments or audit logs disappear on a fixed schedule. Keep the reply with the contract file so the decision is traceable.
What must be re-created by hand in GlitchTip
GlitchTip receives new events through Sentry-compatible SDKs, so the historical events you export from Sentry are archived for reference rather than replayed into GlitchTip. Plan on the first events in GlitchTip arriving only after each application's DSN is pointed at the new instance. Anything that depends on past data, such as trend charts or the full issue history, stays in the archive, not in the GlitchTip interface.
Several configuration items do not travel with the event data and must be rebuilt by hand. These include alert rules for issue creation, regressions and volume thresholds, notification routing to email or webhook destinations, integrations with chat and ticketing tools, team membership and the role each person holds in each project, and any uptime checks or scheduled pings your team relied on. Build an inventory from the Sentry project settings before you export, and assign an owner for each item so none is lost during the move.
Before you commit to a cutover date, read the GlitchTip installation documentation for the environment you will deploy, whether Docker Compose on a single server or the Helm chart for Kubernetes, and confirm whether the version you install supports importing historical events or configuration. Check this with the GlitchTip project directly, because import support may differ between releases, and do not assume it from the Sentry export format. Document the result in your migration record so auditors and on-call staff can see what was archived and what was recreated.
How DeployOpen works on this
DeployOpen plans and implements the export of Sentry data inside your own infrastructure, with the scope agreed in writing before any work starts. The work covers which projects, issues and settings to pull, how the extraction runs against the correct regional API host, and how the results are checked and documented for the GlitchTip side.
How we scope
- Inventory the Sentry organizations, projects, teams and integrations that the export must cover
- Confirm which regional API host each Sentry organization uses before any request is written
- Agree in writing which items are re-created by hand in GlitchTip, such as alert rules and integrations
How we build
- Write extraction scripts that follow cursor pagination and respect the rate limit headers returned by Sentry
- Store exported issues, events and project settings in a format your team can search and verify
- Test the extraction against a sample project before running it across the full organization
How we hand over
- Deliver the scripts, configuration and a runbook describing each step and its expected output
- Document a reconciliation checklist that compares exported record counts with what Sentry reports
- Walk your engineers through the GlitchTip project and team setup that receives the migrated context
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
- Ongoing support, upgrades and re-runs of the export are available as a retainer
- Ask any quote to state which items are excluded, such as historical events beyond your plan's retention
