# Find Slow Vercel Builds

An agent compares Vercel deployment timings and available build logs, then returns a report separating slow phases from queue time and missing evidence.

[Run this on Rush](https://cloud.getrush.ai/run/build-time-report/vercel/).

## What the agent does

The agent reads the authorized Vercel team's projects and deployment metadata through the Vercel connection. Rush's catalog describes project listing, deployment inspection and build-log access for its Vercel MCP connector. Before sending the minimal body below, attach that connected MCP server's id using `connections` in your actual request. No GitHub resource is needed for this report, and a project name in `input` does not attach a Vercel account. The input should name the team and project scope to avoid comparing unrelated deployment streams.

For each selected project, it retrieves the last thirty deployments requested by the prompt and records their identifiers, environments, source revisions, outcomes and available timing fields. It distinguishes time waiting to build from time executing the build, and keeps failed or cancelled attempts visible without mixing them into a successful-build median. Preview and production deployments can do different work, so it compares like environments and notes cache or configuration differences where the returned metadata supports them. Missing phase timestamps remain missing instead of becoming zero-duration steps.

It asks for the build logs of the five slowest comparable attempts and uses timestamped boundaries to identify where time goes. Dependency installation, framework compilation and output collection become separate phases only if the logs provide evidence for that split. Parallel or interleaved log lines do not justify adding overlapping durations together. The agent cites deployment ids and the relevant log excerpts without copying environment secrets. When logs omit enough timing detail, the report identifies the slow build but leaves the most expensive internal step undetermined.

The prompt asks for the first build-time increase above thirty percent. The agent states the denominator, compares chronologically against the preceding successful deployment in the same project and environment, and handles a missing baseline explicitly. It identifies a source revision or configuration change as a correlation until the logs support a cause. `build-times.md` contains per-project summaries, slow-build walkthroughs, the earliest qualifying increase within the retrieved sample and next checks. The agent does not redeploy, alter settings, purge caches or change source.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "Use the attached Vercel MCP connection to inspect the team and projects specified in this task. Report missing scope instead of choosing another team. Read each project's last 30 deployments and available build logs for the slowest five comparable attempts. Write build-times.md with median and slowest successful build duration by project/environment, failed and cancelled attempts separately, evidence for the longest build phases, and the first chronological increase over 30 percent relative to the preceding successful comparable deployment in the sample. Separate queue time, missing timestamps and unproven causes. Cite deployment ids and log boundaries without secrets. Read only: no deploys, cache changes, settings edits or source changes."
}
```

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

`build-times.md` opens with a project-and-environment table showing the sample, timing definition, median, slowest build and excluded attempts. The slow-build section links each conclusion to a deployment identifier and timestamped log boundary. A regression timeline shows the comparison used for the requested increase, along with any missing predecessor or incomplete log window. The report can say which phase dominates without pretending that a deployment metadata field explains its internal cause.

A reviewer checks that preview builds were not compared with a different production command, that queue wait was separated from execution and that cache misses are described as evidence rather than assumed. Suggested next checks stay separate from changes to apply. Rush returns the report through the session's artifact list; the messages retain the inspection steps. This page describes the requested output and does not assert that a particular deployment has already been investigated.

## Run it on every weekly build review

Your scheduler can send a request per Vercel team or selected project group, with a fixed reporting cutoff and the connection attached. A webhook receiver can also start a review after a deployment crosses a threshold your own monitoring defines. Choose an idempotency key for that event and reuse it only when retrying its unchanged request.

Collect the completed session's answer and artifacts by reading it or receiving the key's configured completion webhook. Keep the report with its deployment sample, then compare the same environments next week. Repeated analysis does not authorize automatic cache invalidation or a redeploy intended to test a hypothesis.

## Why run it on Rush?

Finding a slow build often means inspecting metadata for many attempts and reading long logs for a small subset. Rush gives the agent a separate sandbox to sort those records, calculate comparable summaries and write the result. It can do that from the Vercel connection without cloning a repository or rebuilding the application on your laptop.

The trajectory keeps the deployment reads and log evidence associated with the final explanation. When a team questions a suggested cause, the reviewer can inspect the original boundaries instead of trusting an uncited summary. Different project groups can receive separate sessions within your concurrency limit, with each report retaining its own sample and coverage gaps.

## Frequently asked questions

### Can it explain a build without access to source code?

It can compare deployment timings and the evidence present in build logs. That may locate the expensive phase or the revision where time changed. A source-level cause needs additional evidence, so the report labels it unresolved when the connection alone cannot establish it.

### Will failed deployments skew the median?

The requested report separates failed and cancelled attempts from the successful-build summary. It still lists them because a long failed build can matter operationally. The sample definition and exclusions appear beside the calculation.

### What if a log does not expose phase timestamps?

The agent reports the available deployment duration without inventing per-step measurements. It can cite a suspicious phase while keeping its duration unknown. The result explains the evidence needed to narrow the cause.

### Does this change Vercel settings or start another build?

No, the task requests deployment and log reads only. The proposed next checks are review input, not instructions to execute against the team. Use provider-side read-scoped access where available, because prompt wording alone does not restrict a broadly authorized connection.