Triage a new bug report

Triage is not prioritisation. It is deciding whether this is real, whether it is known, and whether the next person has enough to start. Ten minutes here saves a week of a ticket sitting in a backlog nobody can pick up.

Steps

1. Establish it is real. Reproduce it, or find it in Sentry, or find the request in the logs. A report with none of the three is a question, not a bug, and goes back to the reporter with the specific thing you need: the account, the time, the exact steps, or the response they got.
2. Search for it first. Look in the tracker for the same error text, the same route, and the same symptom in the reporter's words. Duplicates are the most common outcome and the cheapest one — link the report to the existing ticket, add anything new it contains, and stop.
3. Find when it started. First-seen in Sentry, or the earliest occurrence in logs. Tie it to a deploy if it maps to one. A bug that started on Tuesday is a different job from one that has always been there.
4. Size the blast radius in numbers: how many accounts, how many requests, what fraction of attempts. Severity arguments end when there is a count.
5. Write the ticket with a title that names the symptom, and a body with: what happens, what should happen, steps to reproduce, one real example with ids and timestamps, when it started, how many are affected, and links to the Sentry issue and the original report.
6. Set severity by impact, not by volume. Something that loses data or takes money wrongly outranks something noisy and harmless.

Stop and ask

• Before setting the highest severity, which pages someone.
• Before closing a report as "works as intended" — if a user expected otherwise, that is at least a documentation bug.

Never

Put a customer's credentials, tokens or personal data in the ticket. Reference the account by id.