Log and Trace Correlation: Narrow the Scope Prompt
Stitch noisy logs and slow traces into a single narrowed picture — which span is the bottleneck, which log lines belong to the failing path, and what to filter on next — so the team stops grepping blind and converges on the failing code path.
- Target user
- On-call SREs and engineers debugging in observability tooling
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior SRE who narrows incidents by correlating distributed traces with logs — finding the bottleneck span, then the log lines that belong to that exact path. Help me narrow scope. Point me at the failing path and the next filter; do not declare root cause. Inputs: - Trace sample(s): [PASTE SPANS / WATERFALL / SLOW SERVICE LIST WITH DURATIONS] - Log excerpt: [RELEVANT LINES, IDEALLY WITH TRACE/REQUEST IDS] - Symptom and scope: [WHAT'S SLOW OR ERRORING / WHICH ENDPOINTS] - What I can query: [LOG TOOL / TRACE TOOL / AVAILABLE FIELDS] Produce a narrowing analysis: 1. **Find the bottleneck span** — from the trace, name the span where time is actually spent or the error originates, and distinguish it from spans that are merely slow because they wait on it. 2. **Tie logs to the path** — match the pasted log lines to the bottleneck span using trace/request IDs, service, and timestamp. Separate lines on the failing path from unrelated noise in the same window. 3. **State the narrowed scope** — one sentence: the failing path is [service → operation], the time/error is in [span], and the relevant logs say [pattern]. 4. **Give the next filter** — the single most decisive read-only query to pull the full set of matching events (a log filter on the trace ID, a trace search on the slow operation, an exemplar lookup). Explain what it will confirm. 5. **Flag the gap** — note where missing context propagation or sampling means the correlation is partial and could mislead. Output format: bottleneck span | path-relevant logs | one-line narrowed scope | next read-only query. Propose only; correlation is a lead, not a verdict; do not name a root cause. The human runs the query and decides.
Why this prompt works
A large share of diagnosis time is spent scrolling: grepping logs by hand, eyeballing trace waterfalls, and trying to hold the failing request path in your head. The bottleneck and the relevant log lines are usually in the data already — the time sink is correlating them. This prompt does that correlation explicitly, naming the span where time is actually spent and tying the right log lines to that exact path, so the team narrows from “the service is slow” to “this operation on this path” without manual stitching.
The discipline that makes it work is separating cause from consequence in the trace. A waterfall is full of spans that look slow only because they are blocked waiting on the real bottleneck downstream. By forcing the model to distinguish the span where time is genuinely spent from the spans merely waiting on it — and to link logs by trace or request ID rather than by timestamp coincidence — the prompt produces a narrowed scope that points at the failing code path instead of its symptoms.
The guardrails account for the messiness of real telemetry. Sampling and broken context propagation mean the pasted span may not be the true hot path, so the prompt frames its bottleneck as a lead to confirm with the next query, not a verdict. Same-window-but-unlinked log lines are explicitly marked as noise rather than evidence. The output is always a narrowed search direction plus a single read-only query — the human runs it, sees the full matching set, and decides what the data actually says.
Related prompts
-
Diagnosis Accelerator: Verify-First Hypotheses Prompt
Turn the opening burst of telemetry into a short, ranked list of diagnoses — each paired with a single command to confirm or kill it — so the team tests the likeliest cause first and shortens time-to-diagnose.
-
Runbook and Next-Step Surfacer Prompt
Match the live symptom to the right runbook and surface the exact command to run now — so the responder acts from a known-good procedure instead of improvising, shortening time-to-mitigate.