Find the services running out of headroom
Reads utilisation across AWS, Cloudflare, PlanetScale and Kubernetes, and ranks services by how close each is to a ceiling.
I want to do this: Which services are closest to their limits: connection pools, queues, compute? ## 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: Find the services running out of headroom Steps: 1. Walk the critical services in the context graph with their current config 2. Read utilisation against each limit: pools, queues, compute, storage 3. Rank services by the headroom left at current growth 4. Check recent changes that moved any of the limits 5. Deliver the ranked list with the series behind each ceiling 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.
Limits announce themselves by being hit.
Pool sizes, queue depths, and instance counts were set once, under last year's traffic. Nobody rechecks them until a deploy pushes one over.
- The connection pool sized for last year's traffic
- Queue depth growing towards a cliff nobody watches
- Capacity reviews that happen after the outage
One prompt, this much work. Every step on your real data.
- 1 Walk the critical services in the context graph with their current config
- 2 Read utilisation against each limit: pools, queues, compute, storage
- 3 Rank services by the headroom left at current growth
- 4 Check recent changes that moved any of the limits
- 5 Deliver the ranked list with the series behind each ceiling
Find the ceiling before you hit it
Every limit and its distance to trouble on one list, from live config and telemetry. The capacity review happens before the outage, not inside its postmortem.
Review the risky one 
“Review PR #241 against production: what does it deploy to, and what breaks if it merges?” Blast radius “If checkout-api goes down, what goes down with it? Walk the graph and rank by traffic.” 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.”
“Review PR #241 against production: what does it deploy to, and what breaks if it merges?” Blast radius “If checkout-api goes down, what goes down with it? Walk the graph and rank by traffic.” 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.”