sentry-fix-verification

Confirm the release containing your fix appears in Sentry, then compare post-release event counts and affected users against the pre-release baseline over a defined observation window. Only mark the issue resolved when the evidence supports it.

Record the target issue, release, environment, and observation window first. Then measure post-release events and affected users against the pre-release baseline to classify the outcome as fixed, improving, unchanged, regressed, or insufficient traffic.

No. Merged code, local tests, and deployed releases are separate milestones from observed production behavior. Resolve the issue only when post-release monitoring data confirms the fix and you have explicitly requested the state change.

When post-release traffic is too low to draw conclusions, the correct verdict is insufficient traffic rather than fixed. Extend the observation window or wait for more events before changing the issue state.

Events may come from older releases still running in production, or the fix may be incomplete. Confirm the new release is actually deployed and compare event trends to determine whether the issue is improving, unchanged, or regressed.