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.
- Target user
- On-call SREs triaging a service failure
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are an SRE triaging a failing service. The fastest MTTR win right now is answering one question correctly: is this our code, or a dependency? Design and walk me through a rapid, read-only health sweep of everything this service depends on and everything that depends on it. Give me: - The failing service and symptom: [SERVICE, ERROR/LATENCY PATTERN] - Its dependencies: [DATABASES, CACHES, QUEUES, INTERNAL SERVICES, THIRD-PARTY APIs] - Its dependents: [WHO CALLS THIS SERVICE] - Available signals: [METRICS, DASHBOARDS, STATUS PAGES YOU CAN CHECK] Work through this: 1. **List the dependency graph tersely.** Upstream (what this service needs) and downstream (what needs it), so the sweep is complete and nothing is forgotten under pressure. 2. **Order the sweep by likelihood and cheapness.** Prioritize the dependencies most likely to be at fault and fastest to check first (a shared database or a flaky third-party API before a rock-solid internal service). Justify the order briefly. 3. **Give a read-only check per dependency.** For each, the specific read-only signal or command that reveals its health from this service's perspective — connection pool saturation, upstream error rate, third-party status plus your own call latency to it, queue depth. Prefer signals that reflect YOUR calls, not just the dependency's global status. 4. **Interpret the pattern.** State what each result would tell you: "if the DB connection pool is exhausted, the fault is likely ours (leak) or the DB's (slow queries) — here's how to tell them apart." 5. **Reach a verdict.** After the sweep logic, state the most probable location of the fault (our code / a specific dependency / a dependent feeding back) with confidence, and the single check that best confirms it. Output format: a "DEPENDENCY SWEEP" — a table of DEPENDENCY, DIRECTION, READ-ONLY CHECK, WHAT-A-BAD-RESULT-MEANS, ordered by check priority — then a VERDICT (+confidence) and NEXT CONFIRMATION. Every check must be non-mutating. Rank the fault-location hypotheses explicitly.
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 huge share of wasted incident time is spent debugging your own service when the fault lives one hop away — a saturated shared database, a third-party API degrading, a downstream service applying backpressure. Responders default to reading their own logs and code first because that is what they control, and the “is it us or them?” question gets answered slowly, by accident, after twenty minutes of dead ends.
This prompt turns that question into a fast, ordered, read-only sweep. It lays out the full dependency graph so nothing is forgotten, orders the checks by likelihood and cost so the cheap high-probability suspects go first, and gives a concrete non-mutating signal for each. Crucially, it prefers signals that reflect your calls to a dependency over the dependency’s global status page, which is where teams get fooled — an upstream can be “all green” for the world and still failing for you.
The guardrails are strict on purpose: every step is read-only, because the reflex to “just restart the cache” or “fail over the database” to test it can convert a contained single-service problem into a real multi-service outage. Answered correctly in the first few minutes, “us or them?” routes the incident to the right team immediately instead of after a wrong-team detour — one of the largest single levers on triage-phase MTTR.
Related prompts
-
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.
-
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.
-
Blast-Radius and Dependency Mapping Prompt
Turn a failing component plus its dependency graph into a scoped blast-radius map — what is affected, what is merely downstream, and what is safe — so the team scopes the incident in minutes instead of guessing at impact.
-
Deploy Correlation: Find the Suspect Change Prompt
Cross-reference incident onset against the deploy, config, and feature-flag changes in the window to produce a ranked list of suspect changes with a fast confirm-or-clear check for each — shrinking the time spent asking 'what changed?'
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.