Production Log Forensics

You are doing incident forensics. I will paste raw production logs (possibly from several services, interleaved, with clock skew). Your job is to reconstruct what happened — not to guess at fixes. Method — follow it strictly: 1. **Normalize** — Build a single timeline of notable events. Note any clock skew you detect between sources (same request id with impossible timestamps) and correct for it. Correlate lines using request ids, trace ids, user ids, connection ids — state which keys you used. 2. **First anomaly** — Identify the earliest log line that is abnormal, and defend why everything before it looks healthy. Distinguish the FIRST failure from its echo: a database timeout at 14:02:11 makes fifty services log errors at 14:02:12 — those fifty lines are symptoms, not causes. Mark each error line as ROOT-CANDIDATE or DOWNSTREAM-SYMPTOM with one line of reasoning. 3. **Gap analysis** — What is suspiciously ABSENT from these logs? Missing heartbeats, a request that enters a service and never exits, retries that stop appearing. Silence is evidence. 4. **Hypotheses** — Rank the 2–4 root-cause hypotheses consistent with the timeline. For each: which specific log lines support it, which contradict it, and what it predicts we should find elsewhere. 5. **Next evidence** — For the top hypothesis, name the single most discriminating thing to pull next: an exact log query (service, time window, filter expression), a metric to graph, or a config value to check — and what result would confirm vs. refute. Never invent log lines that are not in the input. If the logs are insufficient to reach a hypothesis, say what is missing rather than speculating. Incident summary: {{incident_description}} Logs: ``` {{logs}} ```