# Find Why a Vercel Deploy Broke a Next.js Site

An agent compares the broken Vercel deployment with the previous good one, diffs the commits between them, and names the change that broke production, with evidence.

[Run this on Rush](https://cloud.getrush.ai/run/investigate-vercel-deploy/nextjs/), in a Project that has your repository.

## What the agent does

The agent starts with the two deployments. Through the Vercel connection named on the run it lists the project's deployments, finds the one that broke production and the last good one before it, and reads both sides of the evidence: the build logs of the broken deployment for compile-time failures, the runtime logs for request-time errors, and the deployment details for the commit sha, env differences, and the framework version each one ran.

Then it diffs the commits between the two shas in the repository. A storefront like vercel/commerce is small enough to read end to end: about 64 source files in app, components and lib, on Next.js 15.6.0-canary.60 with React 19, pnpm, and no test suite; the test script is a prettier check. That means the commit diff is short and readable, and each changed file can be opened.

The agent reads the changed files with the failure in hand. This template renders every page against the Shopify Storefront GraphQL API through lib/shopify, pinned to the 2023-01 API version, with cached fetch wrappers behind unstable cache tags and a revalidate route for Shopify webhooks; next.config.ts enables experimental partial prerendering and useCache on a canary release. A runtime error like the one thrown when SHOPIFY_STORE_DOMAIN is missing points at an env or config change; a build failure on a canary bump points at the framework change; a page rendering stale or empty product data points at the cache-tag or revalidation path. The agent matches the log lines to the diff instead of guessing.

The report names the change, the evidence, and how to roll forward: revert the commit, restore the env value, or pin the framework back, whichever the logs and diff support. It also says what was checked and cleared, so the rollback targets the cause rather than the most recent change. The prompt says to change no code, and it doesn't.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Production broke after the latest deployment. Through the Vercel connection, compare its build output and runtime logs with the previous good deployment, diff the commits between them in this repository, and write a report naming the change, the evidence and how to roll forward. Change no code.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **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.
2. **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.
3. **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 a report, the run's artifact. It opens with the two deployments side by side: shas, framework and Node versions, env summary, and build state. The middle names the change that broke production, with one section of evidence per source: the failing build or runtime log lines quoted from Vercel, and the commit diff entries that introduced them, read line by line.

The roll-forward section is concrete: the revert command or the env value to restore, the order to do it in, and what to watch on the next deploy to confirm the fix. Because the repository has no tests, the report leans on the deployment evidence rather than a suite, and it says which checks were possible and which were not.

Before rolling back, the reviewer checks that the named commit is actually the one the broken deployment ran, that the quoted log lines come from the broken deployment and not a neighbouring one, and that the roll-forward plan does not discard unrelated changes that shipped in the same window. The trajectory keeps every log read and diff command, so the evidence replays end to end.

## Run it on every failed deploy

Point a deploy hook or your server at Vercel's deployment notifications, and when a production deployment lands in a failed or error state, have your server post this same request naming the project and the broken deployment. One request starts one run, so every bad deploy gets its comparison against the previous good one while both sets of logs are still there.

Set a webhook URL on the API key and Rush posts run.completed or run.failed when the run's turn finishes, carrying the session URL; your server can attach the report to the deploy notification. Name the Vercel connection on every run, since a key run reads only the connections it names.

## Why run it on Rush?

On a laptop this is an archaeology project: the Vercel dashboard in one tab, the runtime logs in another, a local checkout for the diff, and the mental arithmetic of matching shas across all three. On Rush the agent holds the connection, the logs and the cloned repository in one sandbox, matches the deployment shas to the commit range, and writes the report from evidence it actually read.

The report's value is the separation of evidence from theory. Every claimed cause carries the quoted log line and the diff entry behind it, kept in the trajectory, so the rollback decision is a review of sourced facts rather than a vote on suspicion. And when several projects deploy at once, each broken deployment gets its own run and its own report in parallel, instead of waiting in an on-call queue.

## Frequently asked questions

### How does the agent read my deployments and logs?

You connect Vercel once from the console and name the connection on the run; a key run reads only the connections it names. The agent lists projects and deployments, reads build and runtime logs, and inspects deployment details through it, and the report quotes the log lines it relied on.

### Will it roll back the deployment for me?

No. This run changes nothing: no revert, no redeploy, no env edits. The report names the change and gives the roll-forward plan; a human runs the rollback, and a follow-up run can implement a code fix as a pull request.

### My repo is not vercel/commerce. Does the page still apply?

Yes. The method is deployment-agnostic: two deployments, their logs, and the commit range between them. The commerce specifics here show what the read looks like for a small App Router storefront on a canary framework; your repository gets the same treatment against its own config and env surface.

### What if the breakage is an env var, not a commit?

The deployment details carry the env summary, and the agent compares it between the good and broken deployments before weighting the diff. A missing or changed value such as the store domain shows up there, and the runtime log line that fails closed on it is the confirming evidence.

### The build passed but production still broke. Can it find that?

Yes, that is the common case this page covers: the build logs are green and the runtime logs carry the error. The agent reads both sides of both deployments, so a runtime-only regression from a framework or env change is exactly what the comparison is built to catch.