What the agent does
No repository is cloned. The org admin connects Vercel once (OAuth to the Vercel MCP at https://mcp.vercel.com), and the request names that connection. The agent lists every project the team can see, then for each project lists deployments whose creation time falls in the last 14 days. It records state (READY, ERROR, CANCELED), target (production or preview), git branch when present and the deployment id.
For every deployment in an error state it opens the build log through the same connection. It does not redeploy and does not change project settings. From the log it pulls a short fingerprint: the last failing step name when Vercel prints one, plus one representative error line (for example Module not found: Can't resolve '@/lib/…', Type error: …, Error: Invalid next.config, ELIFECYCLE Command failed, or an out-of-memory kill). Deployments that failed for the same fingerprint are grouped; cancellations and manual aborts are counted separately so they do not inflate the failure rate.
It then rolls the numbers up per project: total deployments in the window, successes, failures, cancels and a success rate. Across the team it ranks the failure groups by count and picks the three causes that cover the most failed deployments, each with the fingerprint, the count, one example project and deployment id, and the example log line. When a project's failures are almost all on one branch or one framework version, the report says so without inventing a root cause the log does not support.
The only file written is deployments.md in the sandbox. The agent does not trigger a new deploy, promote a preview, or edit environment variables. If the connection cannot read a project's logs, that project is listed under a skipped section with the error the MCP returned.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the Vercel connection to list deployments across all projects in the last 14 days. For each failed deployment read its build log and classify the error. Write deployments.md with success rate per project, failures grouped by error with an example log line each, and the three causes worth fixing first. Read only; redeploy nothing.",
"connections": [
"vercel"
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is deployments.md as a session artifact with a time-limited download link. It starts with the window (last 14 days) and the team or account the connection reached, then a per-project table of counts and success rate, then failure groups with an example log line and deployment id each, and finally the three causes to fix first.
The transcript keeps the list and log-fetch calls, so a platform engineer can open the same deployment in the Vercel dashboard and confirm the fingerprint. Before filing tickets, a reviewer checks that canceled previews are not mixed into the failure rate and that a one-off outage is not treated as a standing cause.
Run it on every Monday morning
A weekly cron sends this request with the Vercel connection. Each run covers the trailing 14 days, so overlapping weeks still surface causes that keep recurring rather than a single bad day.
On run.completed, your webhook handler downloads deployments.md and posts the three top causes to the platform channel. When a project's success rate drops below a threshold you choose, open an issue that links the session artifact.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Clicking through failed deployments in the Vercel UI across many projects is slow and easy to bias toward the failures you already know. The agent walks every deployment in the window, reads each failed build log once and groups them by the error text, with the raw calls kept in the transcript.
The work stays off your laptop and off production: nothing is redeployed. You can run the same report for several teams or accounts in parallel, each connection named on its own session.
Frequently asked questions
Will it redeploy anything?
No. The prompt says read only and redeploy nothing. The agent lists deployments and reads logs; it does not create deployments, promote previews or change env vars.
How do I attach my Vercel team?
Connect Vercel under your Rush account (OAuth). Pass connections: ["vercel"] or the connection id from GET /me/connections on the session request, as in the sample.
Does it cover preview and production?
Yes. Both targets in the 14-day window are included, and the per-project section can break them out when the mix matters. Say in the prompt if you want production only.
What if a log is truncated?
The agent uses the lines the connection returns and notes when a log looks truncated or empty. Those deployments still count as failures; they go in an unclassified group rather than a guessed fingerprint.