Anyshift meets Sentry cover showing one deployment mapped across its affected Sentry projects.

1. TL;DR

Sentry gives developers application context around errors and releases. Anyshift adds the surrounding production context by connecting services, infrastructure, deployments, dependencies, and ownership in one graph.

Together, they show how a release affects production and which Sentry projects should carry its context.

A new release goes live, Anyshift maps its impact through linked services and Sentry projects, and Sentry receives the release context across every affected project.

2. What Sentry already knows

Sentry groups related events into issues and brings stack traces, distributed traces, logs, commits, and releases into the developer workflow. Seer, Sentry's AI debugging agent, uses issue details, traces, logs, profiles, and codebase context to analyze root cause and propose fixes.

Sentry also uses releases to correlate first-seen events with the version that may have introduced them. When the same release version is assigned to several projects in one organization, Sentry treats it as one release. Its release API accepts the version and the list of project slugs involved.

The integration answers one specific input question: which projects belong in that list when one deployment can affect several services?

3. From one deployment to the affected projects

Anyshift extends release context beyond the service that changed. Its Graph SDK follows production dependencies to identify every Sentry project that should receive the same release.

The SDK ranks recent deployments with deployImpact, follows dependencies with blast, and maps affected production services to Sentry projects.
  • deployImpact ranks recent deployments and selects graph-connector for review.
  • blast follows the path through anyshift-backend and slackbot.
  • `SENTRY_DSN` maps each service to a Sentry project; `environment` excludes sandbox services.

The SDK builds the project list from explicit dependency and environment relationships.

An operator can start the same review from the terminal with the Annie CLI:

annie ask "Which production services and Sentry projects could the latest graph-connector deployment affect?"

This is an impact-mapping question: it scopes a change before an incident rather than explaining a failure after one. annie ask returns the graph-backed context for review; sentry-cli remains the explicit write step.

4. How the result reaches Sentry

Anyshift returns the project list. After review, `sentry-cli` creates the release and records the production deploy in Sentry. Before the write, no matching release exists:

Sentry Releases view before the write, with no matching release.

After the write, the same search returns the release under the source project and shows two additional projects: the downstream services selected from the graph.

Sentry Releases view after the write, showing the release under the source project with two additional projects attached.

Once affected applications report the same release version, Sentry can connect downstream errors to the upstream deployment without developers rebuilding the dependency path by hand.

5. Other integration paths

The same production graph supports other Sentry workflows:

  • Incident investigation: rank recent deployments and infrastructure changes around a Sentry issue.
  • Blast radius and ownership: follow dependencies to show what else may be affected and who owns the path.
  • Seer enrichment: give Seer deterministic production relationships alongside its issue and code context.
  • Pre-deployment review: identify the Sentry projects a release may affect before it ships.

Sentry APM data is also coming soon to the Anyshift graph. Once available, these flows can start from Sentry telemetry and connect it to deployments, Kubernetes and cloud changes, ownership, and blast radius in the same graph.

Have a Sentry workflow where production context is missing? Bring us one case. We will map it with you.