Bug Tracking and Resolution Checklist

Confirm the issue reproduces consistently or document the specific conditions that trigger it (browser version, user role, feature-flag state, tenant). Heisenbugs that only appear once get deprioritized — invest the time now to find a reliable repro recipe.

Record the exact steps, expected vs. actual behavior, and attach Sentry/Datadog trace IDs, browser console output, network HAR, or a Loom screen recording. The point is that the assignee should not have to come back asking "what did you click?"

Use the Bug template — title formatted as "[Area] short description", labels for affected component and environment, link to any related Sentry issue. Paste the repro steps and trace IDs from the prior step rather than describing them again.

Check the affected service in Backstage or the CODEOWNERS file to find the owning team. Don't drop bugs into a generic engineering queue — they sit there. If ownership is genuinely ambiguous, tag the platform team rather than guessing.

Tech lead or triage rotation reviews accuracy and completeness. Common rejections: missing repro steps, user error mistaken for a bug, behavior matches the spec. Push back to the reporter rather than letting an incomplete ticket sit in the backlog.

Search Sentry by error fingerprint and Jira by component label. If duplicate, link with "is duplicated by" and close the new ticket; bump the priority on the original if this report adds new affected customers.

Engineering manager assigns based on code familiarity and current WIP. For SEV1 hotfixes, pull from the on-call rotation rather than interrupting the assigned sprint owner.

The test should fail on the unfixed branch and pass after the fix — that's the proof the fix actually addresses the reported behavior. Skipping this is the most common reason bugs come back six months later after someone refactors the surrounding code.

PR title references the ticket ID. CI must be green — do not bypass branch protection because "the failing test is flaky." Reviewer reads the diff against the regression test, not just LGTM. Keep PRs under ~400 lines; split if larger.

Trigger the Playwright or Cypress suites for the components touched by the fix. Cross-browser matrix matters when the bug was browser-specific. Investigate any new flakes rather than retrying until green.

Bug fixes regress neighbors more often than they regress themselves. Walk the related user paths the customer would touch — login, the affected feature, the settings panel that calls the same API.

Squash-merge the PR, let GitHub Actions or ArgoCD ship the build, and watch the canary error rate and p99 latency for 30 minutes before promoting to 100%. For SEV1 hotfixes, cherry-pick to the release branch and tag a patch version (e.g., v2024.45.1).

Add an entry under the Fixed section with the customer-facing description (not the engineering one). Link the ticket. If the bug was reported via support, write the entry so the support team can copy it into the customer reply verbatim.

Reply on the original support tickets, post in #customer-support with the deployed version, and resolve the status page incident if one was opened. Customers who took the time to file a bug deserve to know it shipped.