Symptom-to-Query Translator Prompt
Turn a vague incident symptom into the exact read-only observability queries — PromQL, LogQL, trace filters, SQL — that confirm or refute a hypothesis, so responders stop hand-crafting queries under pressure and get to evidence in seconds, cutting time-to-diagnose.
- Target user
- On-call SREs and engineers diagnosing incidents against Prometheus, Loki, and tracing backends
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are an observability expert pair-debugging a live incident. The on-call engineer has a symptom and a hunch but is losing minutes hand-writing queries under pressure. Translate the symptom and each hypothesis into the exact **read-only** queries that would confirm or refute it, using our actual stack and label schema. Paste the context: - The symptom: [WHAT USERS/SYSTEMS ARE SEEING] - Leading hypotheses: [E.G. "DB SATURATION", "BAD DEPLOY", "UPSTREAM TIMEOUTS"] - Our observability stack: [E.G. PROMETHEUS + LOKI + TEMPO, DATADOG, CLOUDWATCH] - Relevant metric/label names and log fields we know of: [JOB, SERVICE, NAMESPACE, STATUS, ROUTE, ...] - The service and time window in question: [SERVICE + WHEN IT STARTED] For each hypothesis, produce: 1. **A confirming query** — the metric/log/trace query that, if it returns a certain result, supports the hypothesis. Write it in the real query language for our stack (PromQL, LogQL, trace filter, or SQL), using our actual label names. State what result would confirm vs. refute. 2. **A refuting / control query** — something that should look normal if this hypothesis is wrong, so the engineer can rule it out fast rather than only seeking confirmation. 3. **The signal to read** — exactly which number, series, or pattern in the output matters (e.g. "p99 latency step-change at deploy time", "5xx rate by route", "connection-pool saturation"). Then: 4. **Order the queries** by cheapest-and-most-decisive first, so the engineer runs the highest-information, lowest-cost query before expensive ones. 5. **Flag guesses.** Where you are inferring a label or metric name that may not exist in our schema, mark it clearly and suggest how to list available metrics/labels to confirm. Output format: for each hypothesis, a block with HYPOTHESIS, CONFIRMING QUERY, REFUTING QUERY, SIGNAL TO READ, and a CONFIDENCE note. Every query must be strictly read-only — no writes, deletes, mutations, or admin actions. If a hypothesis cannot be tested with our stated data sources, say what instrumentation is missing rather than inventing a metric.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
A large share of diagnosis time is not thinking — it is typing: recalling the exact metric name, the label selector, the LogQL pipeline, the trace filter syntax, all while adrenaline degrades precision. This prompt targets the time-to-diagnose phase by collapsing that translation step, turning “I think it’s the database” into a runnable, stack-specific query in seconds.
The design guards against the classic LLM observability trap in two ways. First, it demands a refuting query alongside the confirming one, so the engineer can rule a hypothesis out rather than only hunting for evidence that fits — the antidote to confirmation bias that lengthens incidents. Second, it forces the model to flag any metric or label name it is guessing at, because the most dangerous failure here is a query that runs cleanly but silently matches nothing, producing a falsely reassuring flat line.
Ordering queries cheapest-and-most-decisive-first keeps responders from running an expensive unbounded scan that overloads the very observability backend they need during an incident. And the hard read-only constraint means the AI accelerates the search for evidence without ever being able to touch state — the human reads the results and draws the conclusion.
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.
-
Alert Correlation Prompt: Collapse a Storm Into One Incident
Take a flood of simultaneous alerts and group them into a single incident with one probable originating cause, so responders triage one signal instead of fifty — cutting the time lost sorting noise from the real failure.
-
Dependency Health-Sweep Prompt: Is It Us or Upstream?
Run a fast structured sweep of a failing service's upstream and downstream dependencies to answer 'is the problem ours or theirs?' in the first minutes — so responders stop debugging their own code when a database, provider, or downstream is the real fault.
-
On-Call Readiness & Paging-Coverage Audit Prompt
Audit whether a page will actually reach an awake, empowered human fast — rotation gaps, missing fallbacks, stale contacts, unacked escalation — so time-to-acknowledge doesn't silently blow up the front of every incident's MTTR.
More Reduce MTTR with AI prompts & error guides
Browse every Reduce MTTR with AI prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.