Trace a service's blast radius
Walks the graph outward from one service across AWS, Cloudflare, Vercel and Kubernetes, and ranks everything downstream by real traffic.
I want to do this: If checkout-api goes down, what goes down with it? Walk the graph and rank by traffic. ## Setup (skip if Polylane is already set up) Read and follow https://polylane.com/auth.md for non-interactive signup and setup. Start by checking whether I am already signed in; reuse my account and workspace. If the CLI is missing, bootstrap it without starting the interactive wizard: curl -fsSL 'https://polylane.com/setup?ref=prompts' | bash -s -- --install-only Then follow the guide through email verification, workspace selection, source connections, and MCP authentication. Ask me for an email code or OAuth consent only when needed. Verify each step; report pending setup instead of claiming success from installation alone. ## How to work Over MCP: searchTools lists what this workspace exposes, with each tool's schema; call it first. runTool runs one tool, runCode chains several in one call and returns just the answer. search and execute cover the full Polylane REST API: threads, issues, investigations, autofixes, memories. From the terminal: the polylane CLI wraps the same API, with structured output and non-interactive flags everywhere. Reads always work. Write tools appear only if I have opted in, and every write is screened. ## Task: Trace a service's blast radius Steps: 1. Find the service in the context graph and confirm it's the right one 2. Walk the dependency edges outward: what calls it, what it calls, what shares its data stores 3. Rank each dependent by traffic and tier 4. Check recent incidents and changes on the riskiest dependents 5. Deliver the ranked blast radius with the graph edges behind it Ground every claim in data you actually pulled: the query, the log line, the change record. If the data is inconclusive, say so. Ask me before anything that writes.
Everyone has a diagram. Nobody has the truth.
The architecture diagram was right two years ago. The real dependency list lives across DNS records, environment variables, and the heads of whoever built each piece.
- Dependencies discovered at incident time
- Nobody knows which CNAME points at which service any more
- "Should be safe" as the risk assessment
One prompt, this much work. Every step on your real data.
- 1 Find the service in the context graph and confirm it's the right one
- 2 Walk the dependency edges outward: what calls it, what it calls, what shares its data stores
- 3 Rank each dependent by traffic and tier
- 4 Check recent incidents and changes on the riskiest dependents
- 5 Deliver the ranked blast radius with the graph edges behind it
Know what falls before it falls
One answer, ranked by what actually matters, from the live graph rather than the diagram. The risky change gets planned around reality.
Review the risky one “Review PR #241 against production: what does it deploy to, and what breaks if it merges?” Before the migration 
“We're renaming the orders table tonight. Which services, queries, and crons touch it?” Audit the weekend 
“List every deploy since Friday and flag the ones whose metrics moved afterwards.” Honest release notes 
“Write release notes for this week's deploys, including what regressed and what got fixed.” Headroom check “Which services are closest to their limits: connection pools, queues, compute?”
“Review PR #241 against production: what does it deploy to, and what breaks if it merges?” Before the migration “We're renaming the orders table tonight. Which services, queries, and crons touch it?” Audit the weekend “List every deploy since Friday and flag the ones whose metrics moved afterwards.” Honest release notes “Write release notes for this week's deploys, including what regressed and what got fixed.” Headroom check “Which services are closest to their limits: connection pools, queues, compute?”