## The 2 AM problem: errors without deploy context It's 2 AM. Rollbar pages you — your production error rate just spiked 4x. You roll out of bed, open the Rollbar dashboard, and stare at a wall of new occurrences. 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 Rollbar 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 release you ship gets posted to Rollbar as a deploy event with its commit SHA, environment, and timestamp. From then on, Rollbar doesn't just tell you something broke — it tells you what shipped, when, and by whom. Items get attributed to the deploy 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 → item link in plain terms Two views of the same event, one shared key. In Rollbar, **Deploy Tracking** records each release as a deploy event tied to an environment and a Git revision (commit SHA). When occurrences come in, the **Deploys** screen shows a per-environment timeline of every release alongside the items it surfaced. New items that first appear right after a deploy 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 Rollbar integration in DeployHQ [DeployHQ](https://www.deployhq.com) ships a native Rollbar integration — no shell scripts, no `curl` calls to Rollbar's API, no cron jobs. Open your [DeployHQ](https://www.deployhq.com) project, click **Integrations** in the left sidebar, then **New Integration**. Select **Rollbar** from the service picker and fill in the configuration. ![New Rollbar integration screenshot](https://blog.deployhq.com/attachment/a1ef300d-9478-4d31-8bff-b40a9a887690/CL0Dpkf.png) You'll need two things: - **Access Token** : a Rollbar **Project Access Token** with the `post_server_item` scope. Find it in Rollbar under your project's **Settings → Project Access Tokens**. Per [Rollbar's current](https://docs.rollbar.com/reference/post-deploy)[Deploy](https://www.deployhq.com) API documentation, this is the scope required to record deploys against the project. - **Environment** : must exactly match the environment string your Rollbar SDK reports — typically `production` or `staging`. Mismatches are the most common reason deploys don't line up with items, so double-check the spelling. Once you've configured when you want to send notifications and which servers you want to send them for, click **Create Integration**. After that, any successful deployment will post a deploy event to your Rollbar project's **Deploys** screen, where it'll appear with its commit SHA and target environment. ![Rollbar deploy screenshot](https://blog.deployhq.com/attachment/7d80cd61-47b6-4e0a-8ab4-c9864e843d2a/r-OZY6fd.png) The full setup steps live in our [Rollbar integration documentation](https://www.deployhq.com/support/integrations/rollbar) if you need a reference while clicking through. * * * ## Tracking deploys after the integration is live Once configured, run a deployment to any server in your project. [DeployHQ](https://www.deployhq.com) will hit Rollbar's `POST /api/1/deploy` endpoint and a new entry will appear in the **Deploys** screen for the matching environment. From that point forward, items reported to the project gain deploy context: each occurrence is attributed to the release that was live when it happened. The Rollbar dashboard gains a few things that didn't exist before: - **Filter items by deploy** so you can see only what regressed since the last release - **Per-environment deploy timelines** showing error rate against deploy events, so spikes line up visually with shipments - **Regression visibility** — items that reappear in a new deploy after being resolved stand out, instead of getting lost in the firehose 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](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 deploys against Rollbar items today** — [sign up for DeployHQ](https://www.deployhq.com/signup) and wire up the Rollbar 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 Rollbar project tracks a single environment — usually `production`. Two patterns worth knowing: 1. **One Rollbar 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 Rollbar project then sees only its own deploys, and you can alert independently. 2. **Single Rollbar 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 Rollbar's environment filter to separate deploys inside the **Deploys** screen. A common gotcha: if your Rollbar SDK reports `environment` as `production` but the [DeployHQ](https://www.deployhq.com) integration sends `prod` (or `live`, or `prd`), Rollbar treats those as separate environments and silently drops the attribution. Pick one canonical spelling and use it everywhere — the SDK config, the [DeployHQ](https://www.deployhq.com) integration, your environment variables. Rollbar's [environments documentation](https://docs.rollbar.com/docs/environments) covers the consequences in more detail. * * * ## What this unlocks beyond MTTR Faster incident response is the headline win, but tying deploys to items 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 deploy tagging, you're estimating. With it, Rollbar deploys + [DeployHQ](https://www.deployhq.com) releases 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 attribution** falls out of the SHA join. Rollbar knows the deploy; [DeployHQ](https://www.deployhq.com) knows who triggered it. Not for blame — for routing the regression to the engineer with full context. 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) and [Honeybadger deploy tracking with DeployHQ](https://www.deployhq.com/blog/honeybadger-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](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 Rollbar 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 Rollbar and tie items 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 Rollbar 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 [Rollbar's current](https://docs.rollbar.com/docs/deploy-tracking)[Deploy](https://www.deployhq.com) Tracking documentation, the dashboard features that benefit from this — per-deploy item filtering, regression visibility, per-environment timelines — only light up once deploys are being reported, which is exactly what this integration does for you. If you have any questions about the Rollbar 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).