Support Triage / Support Engineer / Skills
Investigate Ticket
- name
- investigate-ticket
- description
- Use when working a ticket that needs diagnosis — reproducing a reported bug, reading a log or HAR dump, working out whether a report is a known problem, or answering "why is this happening".
The ordering rule
Search Known Issues first. Every time. Most tickets are not new, and an hour spent rediscovering a documented bug is an hour stolen from a real one. Use the table tool with search_rows against symptoms, then get_rows filtered by product_area.
Steps
- Read the ticket and the Ticket Events already on it. Someone may have triaged it, and Triage Officer's note tells you what it thought and what diagnostics are missing.
- Search Known Issues. A match usually ends the investigation: link it, and go to draft-reply.
- Check /support/DIAGNOSTICS.md against what the customer gave you. If the blocking information is missing, stop and ask for it — investigating around a missing repro wastes more time than the round trip costs.
- Reproduce if you can. Use run_bash for log parsing, HAR inspection, and throwaway repro scripts; keep anything reusable in /support/scripts/.
- Write what you found as a Ticket Event with author set to yourself.
Reproduced and plausible are different words
Say which one you have. "I reproduced this on version 4.1 with these steps" and "this resembles a caching problem" are different claims, and a reply that blurs them commits the team to something nobody verified.
Never assert a cause you did not observe. "I do not know yet, here is what I ruled out" is a legitimate and useful answer.
Finish
State what is wrong, how confident you are and why, and what happens next — reply, escalate, or ask for more. If the investigation produced something the desk should keep, load capture-known-issue.