Sentry integration
Last updated .
What does the MergeSafe Sentry integration do?
It receives your Sentry projects’ new and regressed issues and, for each project, opens a GitHub issue in a repository you choose, lists the errors in the MergeSafe app, or ignores them. MergeSafe can also analyse each error against that repository’s code and add the possible causes to the GitHub issue.
It is being opened to organizations gradually. If the Integrations page in the app shows Sentry as coming soon, it isn’t on for your organization yet.
What it does
- Open a GitHub issue, while your organization’s GitHub Issues switch is on (on the Integrations page; the same switch tech-debt items follow), for each new error, labelled
bug,needs-triageandsentry. A regressed error (one that comes back after being resolved) adds a comment to its issue instead of opening another. A new Sentry issue from the same project and environment, with the same error type at the same crash site (top in-app frame) as an issue MergeSafe opened that is still open, comments “Seen again” there instead of opening a duplicate, and isn’t analyzed or charged again. Once that issue is closed, the next new Sentry issue with that error opens a new issue instead; a regression of a Sentry issue that already has its own GitHub issue still comments on that issue, open or closed. - Show in MergeSafe only: errors appear under Recent errors in the app, kept for 30 days. This is where errors go while GitHub Issues is off, when you pick it on the Sentry page even with GitHub Issues on, and when GitHub refuses the issue.
- Ignore a project, or turn Sentry Off for every project.
- Analyze it (on unless you turn it off): for an error that opens or updates a GitHub issue, MergeSafe reads that repository’s code and adds the possible causes to the issue, most likely first. 20¢ per analyzed issue; see below.
While GitHub Issues is off, or the Sentry page is set to MergeSafe only, no GitHub issue is opened for any project, including one you pinned to a repository in the projects table: its errors are listed in the app. The pin is kept and applies again once GitHub Issues is on.
Each Sentry project is matched to a repository from the error itself (its in-app stack frame paths and any repository Sentry names). You can pin a project to a repository, list it in the app or ignore it; a default repository for GitHub issues covers projects MergeSafe hasn’t matched to a repository yet (their errors aren’t analyzed automatically until you link the project). A project whose errors name a repository MergeSafe isn’t connected to is listed in the app instead, until you pick a repository for it.
It doesn’t link errors to pull requests or review findings.
What it costs
- Sentry issue analysis: 20¢ per analyzed issue, charged from your organization’s prepaid balance, the same balance reviews use. Opening GitHub issues and listing errors is free.
- Each issue once. Repeat events for an issue MergeSafe already analyzed are free: they aren’t analyzed again.
- A regression is charged again. When an issue returns after being resolved, it is analyzed and charged again, once each time it returns.
- Failed analyses are not charged, nor is one that doesn’t run: at most 20 analyses a day per organization, none when the balance doesn’t cover 20¢, and none once analysis is turned off. An error that isn’t analyzed then can still be analyzed by hand: Analyze now on its row in Recent errors, at the same price. That includes an error only listed in the app: its analysis shows on its row and in the email, nothing is posted to GitHub, and Open GitHub issue on the same row files it (free), with the analysis as the issue’s comment — except when the error has the same root cause as an issue already filed (it is noted on that issue, without the analysis) or its analysis read another repository than the one the issue is filed in (the analysis stays in the app and the email).
- Spending limits apply. Analyses count toward your daily, weekly and monthly spending limits, and a limit set to pause stops them too.
- Turn automatic analysis off (“Analyze each new error” on the Sentry page) and nothing is charged unless someone clicks Analyze now on an error. Each charge shows on the Billing page as “Sentry issue analysis”.
How do I install it?
You need a MergeSafe organization with the GitHub App installed, and you must be an Admin of it. In Sentry you need permission to install integrations.
You can start from either side.
From MergeSafe:
- In app.mergesafe.ai, open your organization’s Integrations page and click Install on Sentry on the Sentry card.
- Sentry opens its install page for MergeSafe. Pick your Sentry organization and approve read-only access to issues and events.
- Sentry sends you back to the app, which shows Installed from Sentry with your Sentry organization. Nothing to copy or paste.
From Sentry:
- Open MergeSafe in Sentry’s integration directory, or go to sentry.io/sentry-apps/mergesafe/external-install/. Pick your Sentry organization and approve read-only access to issues and events.
- Sentry sends you to MergeSafe. Sign in with GitHub if you aren’t already.
- Choose the MergeSafe organization to connect and click Connect Sentry. You must be an Admin of that organization. Finish within 15 minutes, or install again.
One Sentry install links to one MergeSafe organization; an install already linked to another organization is refused.
What permissions does it request, and why?
- Issue & Event: Read. Nothing else. Read access lets MergeSafe receive Sentry’s issue webhooks and see an error’s details (title, level, stack frames) so it can match the error to a repository and describe it. It can’t change, resolve, assign or delete anything in Sentry.
- MergeSafe acts on two issue events: created (a new error) and unresolved (a regression). Other deliveries are acknowledged and dropped.
How do I set it up in the app?
After installing, on the Sentry card in app.mergesafe.ai:
- Under Where errors go by default, pick Follow GitHub Issues (the default: issues open while your organization’s GitHub Issues switch is on; the page says which, and links to it), Show in MergeSafe only or Off.
- Optionally pick a Default repository for GitHub issues, used only for a project MergeSafe can’t match to a repository yet. Errors from such a project open issues there but aren’t analyzed automatically until you link the project to its repository; Analyze now on an error’s row still runs one by hand.
- In the projects table, change any project’s choice: a repository, the app, or ignore. Projects appear there as their first error arrives.
- Leave Analyze each new error on, or turn it off.
- Click Save, then trigger a test error in a Sentry project. It shows under Recent errors within a minute.
Only organization Admins can change these settings.
Self-hosted Sentry: connect an internal integration
If you can’t install from sentry.io, connect a Sentry Internal Integration instead (the app shows these steps under “Self-hosted Sentry?”):
- In Sentry, create an Internal Integration.
- Paste in the webhook URL that MergeSafe shows.
- Set Issue & Event to Read, tick the issue webhook, and leave Alert Action off.
- Paste the integration’s Client Secret into MergeSafe.
- Trigger a test error. It should appear under Recent errors.
What data does it read, and how long is it kept?
- MergeSafe receives Sentry issue events only, with read-only access, and keeps only the fields it uses, never the whole payload: the error’s title, culprit, level, environment, first and last seen times, event count, Sentry link and short id, project, error type and message, its in-app stack frame paths, functions and line numbers, and the names of any repositories Sentry reports for it.
- Per-project settings: for each Sentry project, MergeSafe keeps your choice for it and the evidence used to match it to a repository (in-app file paths and repository names from its errors, no code). They are kept while Sentry is connected and deleted when you disconnect in MergeSafe or uninstall MergeSafe in Sentry.
- Webhook deliveries are held only until they are handled, at most 7 days.
- Recent errors in the app, and the analysis stored with them, expire after 30 days.
- GitHub issues and comments MergeSafe opens live in your repository, under your control, like any other issue.
- Analysis reads the matched repository’s code under the same rules as reviews: code-derived data expires at most 30 days after last use, is encrypted per repository, and is sent only to vetted AI model providers. With automatic analysis off, no code or error details are sent for analysis unless someone clicks Analyze now on an error, which analyzes that one error the same way.
- The Sentry access token (or, for an internal integration, the Client Secret) is stored encrypted and never shown back. Sentry deliveries are checked against its signature.
- Up to 100 deliveries per organization per hour are accepted.
- Billing records of analyzed issues contain no code and are kept for billing.
Related: Security and data retention, Subprocessors.
How do I uninstall it?
- In Sentry, uninstall MergeSafe under Settings › Integrations. Sentry tells MergeSafe, which deletes the stored access token, the link to your organization and your per-project choices and matching evidence straight away; deliveries from that install are then refused.
- In MergeSafe, click Disconnect on the Sentry card. MergeSafe stops receiving errors and deletes its stored Sentry credentials, connection settings, per-project choices and matching evidence. To remove it from Sentry too, also uninstall MergeSafe in Sentry.
- After either, nothing new is opened, listed, analyzed or charged. Errors already listed expire on their 30-day schedule, and GitHub issues already opened stay in your repository.
Support
Questions or problems with the Sentry integration: support@mergesafe.ai. For data and privacy requests: privacy@mergesafe.ai.
Changelog
- 2026-10-14: Per-project data goes with the connection. Disconnecting in MergeSafe or uninstalling MergeSafe in Sentry now deletes each project’s choice and the evidence used to match it to a repository. Reconnecting starts the projects table afresh.
- 2026-10-14: Off means off for pinned projects. A Sentry project pinned to a repository no longer opens GitHub issues while GitHub Issues is off (or the Sentry page is set to MergeSafe only); its errors are listed in the app instead. The pin is kept and applies again once GitHub Issues is turned on.
- 2026-10-14: One GitHub Issues switch. Sentry errors now follow the organization’s GitHub Issues switch on the Integrations page, the same one tech-debt items follow, instead of a GitHub choice of their own. An organization whose errors already opened GitHub issues has the switch turned on for it, with nothing else changed. One whose errors were shown in MergeSafe only keeps that until an Admin picks Follow GitHub Issues on the Sentry page; new connections follow GitHub Issues by default. Errors that were only listed in MergeSafe (GitHub Issues off, or Sentry set to MergeSafe only) aren’t filed when that changes: the Sentry page offers Open issues for N errors under Needs your attention (among the 50 most recent errors it lists), and each one still has Open GitHub issue on its row.
- 2026-10-14: No duplicate issues for a repeat error. A new Sentry issue with the same error and crash site as an open MergeSafe issue comments “Seen again” on it instead of opening another; once that issue is closed, a repeat opens a new one.
- 2026-10-13: Errors only listed in the app. An error that wasn’t sent to GitHub now has Analyze now (its outline shows on its row, the full analysis goes by email) and Open GitHub issue on its row. Errors from a project you set to MergeSafe only or Ignore on the Sentry page still aren’t analyzed; errors listed because the organization’s destination is MergeSafe only are.
- 2026-10-05: Install from Sentry’s side. An install started in Sentry’s integration directory or at MergeSafe’s install link on Sentry now connects to the MergeSafe organization you choose after signing in.
- 2026-10-05: Initial release. Install from Sentry; new and regressed Sentry issues opened as GitHub issues or listed in the app, per project; optional root-cause analysis; uninstall from either side.