Audit the weekend's deploys
Lists every deploy since Friday across Vercel, Render, Cloudflare and Fly, and flags the ones whose metrics moved afterwards.
I want to do this: List every deploy since Friday and flag the ones whose metrics moved afterwards. ## 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: Audit the weekend's deploys Steps: 1. List every deployment and infrastructure change since Friday across connected providers 2. For each, pull the key metrics of the affected service before and after 3. Flag the deploys where a metric moved beyond its normal rhythm 4. Check whether any flagged move already has an issue or investigation 5. Deliver the audit: what shipped, what moved, what needs a look 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.
Monday starts with archaeology.
Three days of deploys across four platforms, and the only record is a scroll through each provider's dashboard. Whether any of them hurt anything is a separate investigation each.
- Four deploy dashboards, none of them linked to the metrics
- A slow regression from Saturday found on Thursday
- "Did anything happen this weekend?" answered with a shrug
One prompt, this much work. Every step on your real data.
- 1 List every deployment and infrastructure change since Friday across connected providers
- 2 For each, pull the key metrics of the affected service before and after
- 3 Flag the deploys where a metric moved beyond its normal rhythm
- 4 Check whether any flagged move already has an issue or investigation
- 5 Deliver the audit: what shipped, what moved, what needs a look
Monday morning in two minutes
The weekend's story on one page: every deploy, every metric that moved, and the ones worth a closer look, before standup starts.
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?” 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?” 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?” 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?”