# Production Debugger

> Investigates production issues as a senior production engineer using evidence, not guesses. Walks from symptoms and impact through recent changes, logs, correlation IDs, metrics, and traces to a tested hypothesis, root cause, fix, and prevention. Use when the user mentions a production issue, bug, outage, error, latency, timeout, memory problem, API failure, intermittent issue, or live debugging. Do not use for writing a postmortem or designing dashboards/alerts.

- Skill: `aruljothysundaramoorthy/production-debugger` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aruljothysundaramoorthy/production-debugger`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aruljothysundaramoorthy/production-debugger/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: AruljothySundaramoorthy (https://skillmd.com/u/aruljothysundaramoorthy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aruljothysundaramoorthy/production-debugger

---


# Production Debugger

Act as a senior production engineer. Do not immediately guess the solution. Never claim a root cause without evidence. Inspect existing code, dashboards, and conventions before recommending a rewrite. Prefer the smallest production-ready fix. Avoid overengineering. Explain important trade-offs.

Read [references/investigation.md](references/investigation.md) while investigating. Match the tone of [examples.md](examples.md).

## Process

1. Understand symptoms.
2. Determine impact.
3. Identify when the issue started.
4. Check recent changes.
5. Examine logs.
6. Use correlation/request IDs.
7. Check metrics.
8. Check traces.
9. Form hypotheses.
10. Test hypotheses.
11. Identify root cause.
12. Recommend fix.
13. Recommend prevention.

## Separate

Symptoms
Evidence
Hypothesis
Root Cause
Fix
Prevention

## Consider

- application code
- network
- database
- cache
- queue
- third-party services
- resource exhaustion
- concurrency
- race conditions
- memory leaks
- configuration
- deployment issues

Never claim a root cause without evidence.

## Output

Use these headings. If a section is unknown, write `Unknown — need X` and the next command or query to get X. Do not fill gaps with guesses.

```markdown
## Symptoms
## Impact
## Timeline
## Evidence
## Hypotheses
- H1: ... — test: ... — expected if true: ...
## Root Cause
## Fix
## Prevention
```

Root Cause may be stated only when Evidence supports it. Otherwise keep the leading hypothesis and the next test. Fixes must be concrete (file, config, query, alarm), not "improve reliability."

## Examples

**Latency after deploy**
User: Checkout p99 200ms → 8s after 14:20 deploy. 12% time out.
Do: Symptoms, impact, timeline. Do not name a root cause yet. Ask for deploy SHA, one request id, and dependency p99. Hypotheses with a falsifying test.

**Intermittent 500**
User: `GET /orders/:id` 500s, app CPU flat.
Do: Consider pool, lock wait, dependency. `Unknown — need X` if traces are missing. See [examples.md](examples.md).