Error monitoring checks

Error monitoring checks are a type of post-deploy Deployment Check that watches a connected error tracker for new issues attributable to the deployment that just finished. After the deploy completes, DeployHQ waits for a configurable window (10, 30, or 60 minutes) and then queries your provider's API for issues whose first-seen timestamp falls after the deploy. Findings surface on the deployment page and, if you have a Slack or Email integration configured with Send on check failed, are pushed to those channels too.

Error monitoring is part of the Deployment Checks beta. Enable beta features on your account to see it in the project sidebar.

How it differs from other Deployment Checks

Every other Deployment Check runs synchronously during the deployment — SSH and HTTP checks at pre-build or post-deploy, vulnerability scans on the build server. Error monitoring is asynchronous: at deploy time DeployHQ records a scheduled step in the deployment timeline and lets the deploy finish. A background sweeper then enqueues the actual provider query once the watch window has elapsed.

The deployment itself is not held open while we wait. It completes normally; the error-monitoring step appears as scheduled and updates in-place when the result arrives.

Setup

You need two things before the check can run:

1. A connected error tracker integration on the same project. Supported: Sentry, BugSink (configure as a self-hosted Sentry integration), Honeybadger, Bugsnag.
2. Read credentials on that integration — for Sentry/BugSink the existing User Auth Token is reused; for Honeybadger and Bugsnag a separate Personal Auth Token plus the numeric Project ID is required. See Required scopes per provider below.

Once the integration is connected with the right credentials, head to Deployment Checks > New Check, choose Post-deploy, then Error monitoring, then fill in:

• Integration — pick from your project's connected error trackers.
• Watch window — how long to watch for new errors after the deploy. 10 / 30 / 60 minutes.
• Minimum severity — findings below this level are ignored. Default is High.
• Match by release tag — when on, only issues tagged with the deployed commit SHA are reported. Recommended when your application's error tracker SDK is configured to set its release tag to the commit SHA.

What the watch reports

When the window elapses, DeployHQ queries your provider for issues that satisfy three filters (all ANDed):

1. First seen after the deployment finished. The strongest signal — excludes every issue that was already firing before this release.
2. In the configured environment. Filters out unrelated environments (a staging deploy won't surface production noise and vice versa).
3. (Optional) Tagged with the release SHA, when Match by release is enabled and your SDK reports it.

What the watch can't tell you: whether a brand-new issue that happens to first-fire during the watch window is actually caused by your release, or just an unrelated edge case a user hit at that moment. Findings are framed as "potential" not "definite" regressions — click through to your provider to see the stack trace and decide.

Required scopes per provider

Provider	What the integration already stores	What error monitoring also needs
Sentry / BugSink	User Auth Token with project:releases scope (used by the deploy notifier)	The same token must additionally have project:read and event:read scopes. If it doesn't, the watch fails with a clear "token lacks event:read scope" message — re-create the token at Settings > Auth Tokens with the right scopes.
Honeybadger	Project API Key (writes deploy notifications via /v1/deploys)	A separate Personal Auth Token (User Settings > Authentication) and the numeric Project ID (visible in the URL when you view the project). The Project API Key cannot read faults. Add both via the Honeybadger integration's settings page.
Bugsnag	Notifier API Key (writes builds to build.bugsnag.com)	A separate Personal Auth Token (My Account > Personal Auth Tokens, with data-access permissions) and the Project ID. The Notifier API Key is not a read credential. Add both via the Bugsnag integration's settings page.

Notifications

By default, findings only appear on the deployment page. To also receive them in Slack or via email, edit your Slack/Email integration and enable Send on check failed — the same flag that fires for other Deployment Check failures.

The notification fires once per watch, at the moment results arrive — typically 10, 30, or 60 minutes after the deploy depending on the window you set. If the watch finds no new issues, no notification is sent.

False positives and how to reduce them

The single biggest cause of noisy results is releases that aren't tagged with the commit SHA on the error tracker side. Without that tag, the watch falls back to the firstSeen + environment filter, which catches every brand-new issue in the window regardless of which release introduced it. To tighten correlation:

• Set your SDK's release to the deployed commit SHA. Sentry: SENTRY_RELEASE environment variable or release: SDK config. Honeybadger: the equivalent revision setting in the client library. Bugsnag: the appVersion setting.
• Then enable Match by release on the check. With both halves in place, only issues bearing this exact deploy's SHA surface.

The other source of noise is a too-short window on a low-traffic application — a 10-minute window may not see any errors simply because nobody hit the new code yet. Bump to 60 minutes for low-traffic apps.

Limits

• One findings page per provider call, capped at 50 issues. A deploy that introduces more than 50 distinct error patterns is unambiguously broken; surfacing more would dilute the alert.
• Spike detection (alerting when an existing issue's event rate jumps after deploy) is not yet supported. The watch only surfaces issues whose firstSeen timestamp is after the deploy.