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 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 problem. Each tool is excellent in isolation. The gap is the missing join: which deploy introduced this error?
DeployHQ 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 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.
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, 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 walks through the moving parts.
Setting up the Sentry integration in DeployHQ
DeployHQ ships a native Sentry integration — no shell scripts, no sentry-cli calls, no cron jobs.
Open your DeployHQ 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/<your-slug>/) 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
productionorstaging. 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:releasesscope. Create it in Sentry under Settings → Account → API → Auth Tokens (or, for organization-level tokens, Settings → Auth Tokens). Per Sentry's current Releases documentation,project:releasesis 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 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 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 — no SSH session, no rerun-from-master gymnastics, no zero-downtime deployment reversed by hand.
Start tracking releases against Sentry issues today — sign up for DeployHQ and wire up the Sentry integration in under five minutes.
Which servers should trigger notifications?
By default, DeployHQ 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:
- One Sentry project per environment (the cleanest setup). Add two DeployHQ integrations — one mapped to your production servers with environment
production, another mapped to your staging servers withstaging. Each Sentry project then sees only its own releases, and you can alert independently. - 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 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 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 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 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, Honeybadger deploy tracking with DeployHQ, and Rollbar deploy tracking with DeployHQ 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 also offers AI-powered deployment log analysis — 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 since 2019, when we shipped it alongside our other error-tracking integrations, and has been quietly working in customer projects ever since. Per Sentry's current Releases documentation, 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, please don't hesitate to email support@deployhq.com or reach out on @deployhq.