Post-deploy Sentry → Slack canary (prod)¶

Linear: ENG-163 (parent ENG-161 zero-error production) · Script: scripts/ci/post-prod-deploy-sentry-to-slack.ps1

What it does¶

After a release is actually live in prod it checks Sentry for net-new unresolved issues and posts a summary to the Release Manager Slack channel — a green check when clean, a warning with the offending issues when not.

✅ Prod deploy healthy — no net-new Sentry issues
⚠️ Prod deploy — 3 net-new Sentry issue(s)   (with level / events / users / links)

Why it runs as an AzDO release task (not a timed GitHub job)¶

The prod release has a manual approval gate. The deploy completes at an unknown time after the Test→Prod PR merges — minutes, hours, or days later, once someone approves the gate. So nothing anchored to the PR merge (a timer, or "poll raklet.com from merge") can know when prod is actually serving the new build. The only reliable signal is the AzDO prod stage reaching succeeded after the gate. Running this as the final task of that stage fires at exactly that moment — no polling, no state, no release-definition lookup.

It sits right next to the existing Deployment.Scripts/SlackMessage.ps1 (same Slack channel / webhook).

How net-new is detected¶

Union of two signals (deduped), read after a bake window so real prod traffic has exercised the new release:

Signal	Meaning
`release`	`firstRelease == <deployed SHA>` — the `Sentry:Release` App Config value set by `sentry-release.yml`.
`window`	`firstSeen >= deploy-completed time` — catches regressions that surface during the bake even if release tagging lags.

window is the primary signal: the AzDO artifact commit (BUILD_SOURCEVERSION) is not guaranteed to equal the Sentry release name (the prod branch merge SHA), so firstRelease only adds precision when they coincide.

A short post-deploy window only catches fast-firing regressions. Slow-burn issues are still covered by the ongoing ENG-165 prod burndown and the promotion-PR report (post-sentry-new-issues-to-pr.ps1).

Wiring it into the AzDO prod release (one-time)¶

In the prod / raklet.com deployment stage of the release definition, add a PowerShell task as the last step (after the deploy + after SlackMessage):

Type: PowerShell (pwsh)
Script path: scripts/ci/post-prod-deploy-sentry-to-slack.ps1
Run condition: Only when all previous tasks have succeeded (default) — we only report on a successful deploy.
Add a SECRET release variable SENTRY_AUTH_TOKEN = a Sentry auth token with project:read (issues) scope (same token as the SENTRY_AUTH_TOKEN GitHub secret used by sentry-release.yml).

Optional pipeline variables:

Variable	Default	Purpose
`SLACK_WEBHOOK_URL`	Release Manager webhook	Override the Slack destination.
(task arg) `-BakeWindowMinutes`	`15`	Minutes to wait before reading Sentry.

The script reads the rest of its context from the standard AzDO release variables it inherits automatically: BUILD_SOURCEVERSION (deployed SHA), RELEASE_RELEASENAME (build label), RELEASE_RELEASEWEBURL (link back).

Classic AzDO releases snapshot their definition per run — this task only takes effect on releases created after it is added.

Rehearse locally (no Slack post, no wait)¶

# Dry-run against live prod Sentry, backdated window to see real issues:
$env:SENTRY_AUTH_TOKEN = '<token>'   # or rely on scripts/dev/load-agent-env.ps1
pwsh -File scripts/ci/post-prod-deploy-sentry-to-slack.ps1 `
  -SkipBake -DryRun -Environment prod `
  -DeployCompletedUtc '2026-06-19T08:00:00Z'

-DryRun prints the Slack payload instead of posting. -UseSampleIssues renders the warning layout without calling Sentry.

Safety¶

Monitoring must never red-out a successful deploy: every error path (missing token, Sentry API error, Slack failure) logs a warning and exits 0. A missing token still posts a degraded :grey_question: note so silence is never ambiguous.