Use case
How do you approach this?
How to Investigate a Production Bug
Published · Updated
Published by Unrust. Scoring and editorial method
Quick answer
Investigate a production bug by separating impact management from diagnosis. First protect users and preserve logs, inputs, timing, and deployment context; then form one concrete hypothesis at a time and choose the smallest observation that can change your confidence. A fluent fix proposal may be useful as a lead, but the incident record and reproducible evidence should decide whether it is safe.
Stabilize before explaining
Rate-limit, roll back, feature-flag, or otherwise reduce harm when that is safer than changing code under pressure. Preserve the evidence around the failure before retries, cleanup jobs, or new deployments overwrite it. This gives later debugging a factual starting point instead of a story assembled after the system changed.
Use cheap discriminating checks
List competing explanations and look for the smallest observation that separates them: one request trace, one database row, one version comparison, or one controlled reproduction. Avoid changing several variables at once because an apparent recovery then gives little information about the actual cause.
Keep the exact input that explains a NaN count
Count occurrences of an ordinary string category in a fresh Map. The first occurrence should be one, and later occurrences should increment it. Reproduce the data operation locally before investigating infrastructure.
The map returns undefined for a new key; adding one produces NaN. Initializing the missing count fixes the reproduced cause. In a real incident, retain the original evidence and check whether concurrent updates require a transactional counter.
The outcomes below are checked by executable tests against the exact displayed snippets. NaN and undefined are written by name so they remain visible in the table.
function run(categories) {
const counts = new Map();
for (const category of categories) {
counts.set(category, counts.get(category) + 1);
}
return [...counts];
}function run(categories) {
const counts = new Map();
for (const category of categories) {
counts.set(category, (counts.get(category) ?? 0) + 1);
}
return [...counts];
}| Arguments to run | Before | After |
|---|---|---|
| ["api", "api"] | [["api", NaN]] | [["api", 2]] |
| [] | [] | [] |
Practice loop
- 01Record user impact, observed behavior, expected behavior, timestamp, and deployment context before editing code.
- 02List two competing causes and choose the quickest observation that distinguishes them.
- 03After mitigation, add a focused regression check and document the signal that would reveal recurrence.
Limits of this page
This page is a reasoning aid, not incident-response policy for every system. Production work can require escalation, security procedures, rollback authority, and operational knowledge; one diagnostic session cannot explain why an incident was difficult or predict performance under pressure.
Source context
Published by Unrust as practical teaching material using public language documentation and original examples. See the scoring and editorial method for scope, checking and limitations.
Check your own starting point
One diagnostic session is a snapshot, not causal proof of why a result occurred. It can help you choose a focused next practice step without making a broader claim about your ability.
Take the free diagnostic