How do you handle a bug that's not reproducible?

Non-reproducible bugs are the hardest part of QA work because the temptation is to close them and move on. That's almost always wrong — the bug happened to a real user once, so it'll happen again.

My triage:

1. Capture everything I can while the trace is fresh. Browser console, network HAR, screenshots, exact URL, user account, time of day, device/OS/browser version, what the user clicked just before, recent deploys. Half of "cannot reproduce" comes from incomplete context.
2. Hunt for the variable I'm missing. Try the same flow with a different user (permissions?), different test data (specific record?), at a different time (race condition? cron job?), with cleared cache (stale state?), in a different region (CDN? data centre?).
3. Check shared state. Is the bug only reproducible after a specific other action? Is it tenant-specific? Is it triggered by a feature flag rollout?
4. Look at recent changes. Diff the last few deploys; check error monitoring (Sentry, Datadog) for similar exceptions. Many "non-reproducible" bugs are visible in error tooling that the developer just didn't check.
5. If I still can't reproduce in 30–60 minutes, I escalate. Engineering can read code paths I can't; sometimes a developer spots a race condition or null-handling gap from the symptom alone.
6. If we can't catch it from the desk, instrument. Add logging around the suspected area, deploy, wait. Or ask the user (if available) to enable verbose logging the next time it happens.

The bug stays open with the conditions documented. Closing it as "cannot repro" without instrumentation just hides it until it surfaces louder.