The 2 AM problem: errors without deploy context
It's 2 AM. Bugsnag pages you — production error rate just jumped 4x. You roll out of bed, open the dashboard, and stare at a wall of new exceptions. 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 Bugsnag 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 release you ship gets posted to Bugsnag as a tagged event with its commit SHA, environment, and timestamp. From then on, Bugsnag doesn't just tell you something broke — it tells you what shipped, when, and by whom. Errors get grouped by release. Regressions surface against the deploy 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 Bugsnag, a release is a tagged event in time, attached to a specific app version and commit SHA. When errors come in, Bugsnag attributes each one to the release that was live when it happened. New errors that 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, an 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 Bugsnag integration in DeployHQ
DeployHQ ships a native Bugsnag integration — no scripts, no webhooks, no cron jobs.
Open your DeployHQ project, click Integrations in the left sidebar, then New Integration. Select Bugsnag from the service picker and fill in the configuration.
You'll need three things:
- Location: choose Cloud for the standard Bugsnag SaaS, or On-Premise if you're running a self-hosted instance (more on that below).
- Environment name: must exactly match the
releaseStageyour Bugsnag notifier reports — typicallyproductionorstaging. Mismatches are the most common reason releases don't show up against errors, so double-check this string. - Notifier API Key: find it in Bugsnag under your project's Settings area. It's the same key your notifier library already uses.
Enable the option to trigger the integration when a deployment finishes successfully, keep all servers enabled (unless you only want to track a subset — see below), then click Create integration.
Self-hosted Bugsnag
If you're running Bugsnag On-Premise, select On-Premise under Location and add your Installation URL — the base URL of your internal Bugsnag instance. Everything else is identical. Same Notifier API Key, same environment string, same SHA-based join.
The full setup steps live in our Bugsnag 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 will notify Bugsnag and a new release will appear in the Releases view.
From that point forward, any exception reported to the project gets linked to the release that was live when it occurred.
The Bugsnag dashboard gains a few things that didn't exist before:
- Filter errors by release so you can see only what regressed since the last deploy
- Regression detection — Bugsnag surfaces errors that reappear in a new release after being fixed
- Per-release timelines showing error rate against deploy events, so spikes line up visually with shipments
If a release goes wrong, you have everything you need to act: the offending commit SHA, the deploy 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 errors today — sign up for DeployHQ and wire up the Bugsnag 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 Bugsnag project tracks a single environment — usually production.
Two patterns worth knowing:
- One Bugsnag 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 Bugsnag project then sees only its own releases, and you can alert independently. - Single Bugsnag 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 the environment string to separate releases inside Bugsnag's UI.
A common gotcha: if your Bugsnag notifier sets releaseStage to production but the DeployHQ integration sends environment prod (or live, or prd), Bugsnag treats them as separate environments and silently drops the release attribution. Pick one canonical spelling and use it everywhere — the notifier config, the DeployHQ integration, your environment variables.
What this unlocks beyond MTTR
Faster incident response is the headline win, but tying releases to errors 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 it, Bugsnag releases + DeployHQ deploys give you 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 error attribution falls out of the SHA join. Bugsnag knows the release; DeployHQ knows who triggered it. Not for blame — for routing the regression to the engineer with full context.
If your stack also includes Honeybadger or Rollbar, the same pattern applies — we shipped Honeybadger deploy tracking with DeployHQ using identical mechanics, and Rollbar notifications work the same way. 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 Bugsnag 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 Bugsnag and track exceptions between releases — without writing a single line of integration code. Two minutes of setup; permanent context on every error.
The integration has been part of DeployHQ since 2019 (we shipped it alongside our other error-tracking integrations) and has been quietly working in customer projects ever since. Per Bugsnag's current documentation on release tracking, the dashboard features that benefit from this — filtering by release, regression detection, per-release error counts — only light up once releases are being reported, which is exactly what this integration does for you.
If you have any questions about the Bugsnag integration or any other aspect of DeployHQ, please don't hesitate to email support@deployhq.com or reach out on @deployhq.