Find the root cause and prove it
Lines up the regression in Datadog with deploys and config changes across AWS, Vercel and Cloudflare until it can name the cause and prove it.
I want to do this: P99 on checkout-api doubled at 14:10. Find the cause and show the evidence. ## 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 root cause and prove it Steps: 1. Pin down the regression window from the metric itself 2. List every deploy, config change, and infrastructure change in and just before the window 3. Test each candidate against the telemetry: does the timing and mechanism actually hold? 4. Check the context graph for upstream and downstream effects that confirm or kill each theory 5. Deliver the cause with the query, the change record, and the mechanism, or say it's inconclusive 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.
Correlation is easy. Proof takes all afternoon.
Three things changed around 14:10 and any of them could be the cause. Proving which one means queries across metrics, deploy history, and config diffs, and most teams stop at the first plausible answer.
- The first plausible theory shipped as the answer
- Deploy history in one tab, metrics in another, config in a third
- Postmortems that say "likely caused by" forever
One prompt, this much work. Every step on your real data.
- 1 Pin down the regression window from the metric itself
- 2 List every deploy, config change, and infrastructure change in and just before the window
- 3 Test each candidate against the telemetry: does the timing and mechanism actually hold?
- 4 Check the context graph for upstream and downstream effects that confirm or kill each theory
- 5 Deliver the cause with the query, the change record, and the mechanism, or say it's inconclusive
An answer you can defend
The cause arrives with the exact queries and the change behind it. When someone asks "how do we know?", the answer is a link.
What broke overnight? 
“Triage everything that fired overnight: what was real, what was noise, and what's still open?” Postmortem “Write the postmortem for yesterday's incident: timeline, root cause, and the follow-ups.” First responder “We're seeing 500s on api.example.com. Start an investigation and post findings to #incidents.” What changed? 
“Did anything deploy or change config in the last two hours that could explain this latency?” War-room brief “Summarise the open incident for the exec channel: impact, cause so far, next steps.” Close the loop “The incident is resolved. Draft the permanent fix and link the evidence.” Which release? “Errors started around Tuesday. Which release introduced them?” Dedupe the pager “Group last month's pages into distinct issues. How many were the same thing twice?” Audit the alerts “Go through our alert rules: which ones fire the most, and which were ever real?”
“Triage everything that fired overnight: what was real, what was noise, and what's still open?” Postmortem “Write the postmortem for yesterday's incident: timeline, root cause, and the follow-ups.” First responder “We're seeing 500s on api.example.com. Start an investigation and post findings to #incidents.” What changed? “Did anything deploy or change config in the last two hours that could explain this latency?” War-room brief “Summarise the open incident for the exec channel: impact, cause so far, next steps.” Close the loop “The incident is resolved. Draft the permanent fix and link the evidence.” Which release? “Errors started around Tuesday. Which release introduced them?” Dedupe the pager “Group last month's pages into distinct issues. How many were the same thing twice?” Audit the alerts “Go through our alert rules: which ones fire the most, and which were ever real?”