## The 2 AM problem: errors without deploy context It's 2 AM. Sentry pages you — your production error rate just spiked 4x. You roll out of bed, open the Sentry dashboard, and stare at a wall of new issues. The team shipped five deploys today. Which one broke it? You open [DeployHQ](https://www.deployhq.com) in another tab. You squint at timestamps. You cross-reference commit SHAs against the stack traces. Maybe you guess. Maybe you roll back the wrong release. The next morning, the team has to reconstruct what actually changed — and the on-call has a coffee, not a story. This isn't a Sentry problem or a [DeployHQ](https://www.deployhq.com) problem. Each tool is excellent in isolation. The gap is the missing join: which deploy introduced this error? [DeployHQ](https://www.deployhq.com) closes that gap. Every shipped deploy gets posted to Sentry as a release with its commit SHA, environment, and timestamp. From then on, Sentry doesn't just tell you something broke — it tells you what shipped, when, and by whom. Issues get attributed to the release that was live. Regressions surface against the release that caused them. [One-click rollback in DeployHQ](https://www.deployhq.com/features/one-click-rollback) becomes the obvious next move instead of a guess. The cost of _not_ wiring this up compounds. Longer mean time to recovery. Blame games. And the cultural drift where deploys quietly become scary events that get pushed to Tuesday afternoon to be safe. If you've ever stalled a release on a Friday because the team was too tired to handle a regression, you've felt this gap. For the broader principle, see our take on [what you should be monitoring on every deployment](https://www.deployhq.com/blog/monitoring-your-deployments-with-deployhq-ensuring-smooth-releases). * * * ## The deploy → release link in plain terms Two views of the same event, one shared key. In Sentry, a **release** is a version of your code deployed to an environment, tagged with a commit SHA. When issues come in, Sentry attributes each one to the release that was live when it occurred. New issues that first appear right after a release are the ones you care about most — they're regressions, not background noise. In [DeployHQ](https://www.deployhq.com), a **deploy** is the act of building that commit and pushing it to a specific environment. Each deploy has a SHA, a target environment (`production`, `staging`), and a timestamp. The join key is the **commit SHA**. Not timestamps — clock drift between systems will burn you. Not deploy IDs — those are internal to each tool. Just the SHA. If both systems know the SHA of the code that's running, they can answer which deploy introduced this error? without anyone guessing. This matters more once you're shipping continuously. With a release a week, you can hold the last five SHAs in your head. With five a day, you can't — and you shouldn't have to. If that part of the picture is fuzzy, our primer on [continuous deployment workflows](https://www.deployhq.com/blog/what-is-continuous-deployment) walks through the moving parts. * * * ## Setting up the Sentry integration in DeployHQ [DeployHQ](https://www.deployhq.com) ships a native Sentry integration — no shell scripts, no `sentry-cli` calls, no cron jobs. Open your [DeployHQ](https://www.deployhq.com) project, click **Integrations** in the left sidebar, then **New Integration**. Select **Sentry** from the service picker and fill in the configuration. You'll need four things: - **Organization Slug** : the URL-safe identifier of your Sentry organization. Find it in the URL when you're signed into Sentry (`sentry.io/organizations//`) or under **Settings → General**. - **Project Name** : the project inside that organization where releases should be posted. - **Environment** : must exactly match the environment string your Sentry SDK reports — typically `production` or `staging`. Mismatches are the most common reason releases don't line up with issues, so double-check the spelling. - **Auth Token** : a Sentry auth token with the `project:releases` scope. Create it in Sentry under **Settings → Account → API → Auth Tokens** (or, for organization-level tokens, **Settings → Auth Tokens** ). Per [Sentry's current Releases documentation](https://docs.sentry.io/product/releases/), `project:releases` is the scope required to create releases for the project. If you're running self-hosted Sentry, also fill in the **Installation URL** — the base URL of your internal Sentry instance. Everything else is identical. Pick the events that should trigger the integration (a successful deployment is the common choice), select the servers you want it to fire for, and click **Create Integration**. The full setup steps live in our [Sentry integration documentation](https://www.deployhq.com/support/integrations/sentry) if you need a reference while clicking through. * * * ## Tracking releases after the integration is live Once configured, run a deployment to any server in your project. [DeployHQ](https://www.deployhq.com) posts a new release event to your Sentry project, where it'll appear in the **Releases** area for the matching environment. From that point forward, issues reported to the project gain release context: each event is attributed to the release that was live when it happened. The Sentry dashboard gains a few things that didn't exist before: - **Filter issues by release** so you can see only what regressed since the last shipment - **Per-release timelines** showing issue counts against release events, so spikes line up visually with deploys - **Regression detection** — Sentry surfaces issues that reappear in a new release after being marked resolved - **Crash-free release tracking** for applications using Sentry's session tracking If a release goes wrong, you have everything you need to act: the offending commit SHA, the release that introduced it, and the engineer who shipped it. From there it's a one-click rollback in [DeployHQ](https://www.deployhq.com) — no SSH session, no rerun-from-master gymnastics, no [zero-downtime deployment](https://www.deployhq.com/features/zero-downtime-deployments) reversed by hand. > **Start tracking releases against Sentry issues today** — [sign up for DeployHQ](https://www.deployhq.com/signup) and wire up the Sentry integration in under five minutes. * * * ## Which servers should trigger notifications? By default, [DeployHQ](https://www.deployhq.com) fires the integration for every server in the project. Keep this on if your Sentry project tracks a single environment — usually `production`. Two patterns worth knowing: 1. **One Sentry project per environment** (the cleanest setup). Add two [DeployHQ](https://www.deployhq.com) integrations — one mapped to your production servers with environment `production`, another mapped to your staging servers with `staging`. Each Sentry project then sees only its own releases, and you can alert independently. 2. **Single Sentry project, multiple environments**. Use one integration but set up server-group filtering so only deploys to specific server groups fire the notifier. Then rely on Sentry's environment filter to separate releases inside the **Releases** view. A common gotcha: if your Sentry SDK reports `environment` as `production` but the [DeployHQ](https://www.deployhq.com) integration sends `prod` (or `live`, or `prd`), Sentry treats those as separate environments and silently drops the release attribution. Pick one canonical spelling and use it everywhere — the SDK config, the [DeployHQ](https://www.deployhq.com) integration, your environment variables. * * * ## What this unlocks beyond MTTR Faster incident response is the headline win, but tying releases to issues changes day-to-day work in subtler ways too. - **Change failure rate** becomes measurable. One of the four DORA metrics — change failure rate — is the percentage of deploys causing degraded service or requiring remediation. Without release tagging, you're estimating. With Sentry releases + [DeployHQ](https://www.deployhq.com) deploys, you have a clean ratio. - **Deploys stop being scary**. Teams that can pinpoint the failing release in seconds ship more often, not less. Friday afternoons stop being off-limits. - **Post-incident reviews get shorter**. Instead of debating did this start before or after the 14:32 deploy?, the timeline is the answer. - **Per-author attribution** falls out of the SHA join. Sentry knows the release; [DeployHQ](https://www.deployhq.com) knows who triggered it. Not for blame — for routing the regression to the engineer with full context. - **Crash-free release health**. Once releases are reported, Sentry's release-health features (adoption tracking, crash-free percentages, regression surfacing) light up for applications using its session tracking. If your stack uses a different error tracker, the same pattern applies — we shipped [Bugsnag deploy tracking with DeployHQ](https://www.deployhq.com/blog/track-deployments-in-a-bugsnag-project), [Honeybadger deploy tracking with DeployHQ](https://www.deployhq.com/blog/honeybadger-deploy-tracking-with-deployhq), and [Rollbar deploy tracking with DeployHQ](https://www.deployhq.com/blog/rollbar-notifications) using identical mechanics. The point isn't which error tracker you use — it's that errors without deploy context cost more than they should. For teams that want every deploy log analyzed automatically (not just notified), [DeployHQ](https://www.deployhq.com) also offers [AI-powered deployment log analysis](https://www.deployhq.com/blog/introducing-deployhq-log-intelligence-your-ai-powered-deployment-log-analyzer) — so the next-step decision after a Sentry spike isn't scroll through 3,000 lines of build output but read the summary. * * * ## Wrapping up You'll now be able to report every deployment to Sentry and tie issues back to the release that caused them — without writing a single line of integration code. Two minutes of setup; permanent context on every error. The Sentry integration has been part of [DeployHQ](https://www.deployhq.com) since 2019, when we shipped it alongside our other [error-tracking integrations](https://www.deployhq.com/blog/deployhq-integrations), and has been quietly working in customer projects ever since. Per [Sentry's current Releases documentation](https://docs.sentry.io/product/releases/), the dashboard features that benefit from this — filtering by release, regression detection, per-release timelines, crash-free tracking — only light up once releases are being reported, which is exactly what this integration does for you. If you have any questions about the Sentry integration or any other aspect of [DeployHQ](https://www.deployhq.com), please don't hesitate to email [support@deployhq.com](mailto:support@deployhq.com) or reach out on [@deployhq](https://x.com/deployhq).