1// Primary threshold (p95>500 AND inv>=1400) WHY: 1.4k/14d is the floor where p95 stabilizes statistically2// and a 3-5x performance win still pays for engineering time. Secondary (p95>1500 AND inv>=250) catches "catastrophically3// slow at any volume" — usually a broken sync call or cold-start chain the customer wants to know about.4//5// 5xx disqualifier: when error rate >50% the route is failing, not slow — latency reflects crash time,6// not work time. route_errors covers it independently; we disqualify here so budget isn't spent on a7// sub-agent that will correctly abstain.89import { withRouteShapeWarnings } from '../route-normalize.mjs';1011const ERROR_RATE_DISQUALIFY_THRESHOLD = 0.5;12
20 'Routes with p95 function duration above 500ms at meaningful traffic (>=1,400 invocations in window), OR catastrophically slow routes (>1500ms p95 at any volume >=250). High duration drives both function-duration cost and user-perceived latency. Investigate sequential awaits, slow external APIs, missing caching, N+1 patterns. Routes with >50% 5xx rate are disqualified — those are reliability problems, not performance tuning targets, and surface via route_errors instead. Vercel Workflow runtime endpoints (`/.well-known/workflow/v1/*`) are hard-gated before launch because long-running step/flow requests are expected orchestration, not app-route bottlenecks.',
39 question: `What is the concrete bottleneck in ${r.route} (p95=${r.p95Ms}ms over ${r.invocations} invocations), and which file-level change would reduce it?`,