--- name: vercel-failed-deployments description: "Three times a day: Vercel production and preview deployments that failed in the last 24 hours, the step and error line, and an ask on whether to redeploy. Use when the user asks for this, or when it runs on a schedule." --- # Vercel failed deployments alert Three times a day: Vercel production and preview deployments that failed in the last 24 hours, the step and error line, and an ask on whether to redeploy. Vercel keeps serving the last good deployment when a build fails. That is right for your visitors, and it is also why a broken production build can sit unnoticed until someone asks why their fix is not live. The agent lists deployments in the ERROR state, reads each build log to find the line that actually failed, and separates production from preview. Preview failures fixed by a later push are reported as fixed. For a production failure it asks you directly whether a redeploy would help or whether to read the log first. ## Two ways to get the data Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used. ## Route A: API or MCP server ### What you need - A Vercel access token created under Account Settings > Tokens and scoped to the team, in `VERCEL_TOKEN`, plus the team ID. - Or the Vercel MCP server or connector, or the `vercel` CLI signed in to that team. If something is missing, say what and stop; do not invent numbers. ### Steps 1. **List failed deployments** (Vercel): `GET /v7/deployments?state=ERROR&since=&limit=50&teamId=`, once with `target=production` and once with `target=preview`. Keep `uid`, `name`, `url`, `created`, `creator.username`, and the branch and commit from `meta.githubCommitRef` and `meta.githubCommitSha` (GitLab and Bitbucket use the matching `gitlab*` and `bitbucket*` keys). 2. **Find the error** (Vercel): `GET /v3/deployments/{id}/events` returns the build log; take the first `stderr` line that reads as an error, plus the lines just before it. `GET /v13/deployments/{id}` adds `errorCode` and `errorMessage` for failures outside the build, such as an invalid `vercel.json`. From the CLI: `vercel inspect --logs`. 3. **Check whether it is still broken** (Vercel): Read the newest deployment for the same project and branch (`projectId` and `branch` on the list call). If it is `READY`, mark the failure as fixed by a later push. 4. **Ask before redeploying**: For a production failure that is still failing, say whether a redeploy is likely to help (a transient install or network error) or not (a code error), then ask. Never redeploy on your own; run `vercel redeploy ` only after a yes. ## Route B: the browser ### What you need - Signed in to Vercel as a team member who can open the project; a Viewer seat can read deployments and logs, while redeploying needs the Member or Owner role. If something is missing, say what and stop; do not invent numbers. ### Steps Start at https://vercel.com/dashboard. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears. 1. **Pick the team and project**: Use the team switcher in the top left to select your team, open the project (acme-web) and click **Deployments** in the sidebar. Repeat the next two steps for each project you care about. 2. **Filter to failures**: In the filter row set **Status** to `Error`, **Date Range** to the last 24 hours and leave **All Environments**. Each row shows the environment (Production or Preview), the branch, the commit message and who pushed it. 3. **Read the build log**: Open each failed deployment and expand **Build Logs**. Find the first red line and the command that was running, usually the lines around `Error: Command "next build" exited with 1`. Note the time. 4. **Check whether it is still broken**: Clear the Status filter and set **Branch** to that branch. If a newer deployment of the same branch is Ready, the failure was fixed by a later push. For production, the row marked **Current** is what visitors get now. 5. **Ask before redeploying**: For a production failure that is still failing, say whether a redeploy is likely to help (install or network error) or not (type or code error) and ask. Only after a yes, open the row's `...` menu, choose **Redeploy** and confirm in the **Redeploy to Production** dialog. Note: The Deployments page filters one project at a time, so a team with many projects is quicker through the API route. Build logs are kept for the life of the deployment, but a deployment deleted by a retention policy takes its log with it. ## The report - **Failed deployments** in the last 24 hours, production first. - For each: project, branch, commit, who pushed it, the failing command and the error line. - **Still failing** or **fixed by a later deploy**. - For production: which deployment is live now, and the ask to redeploy, read the log or leave it. ## Post it to Briefkin When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on. ```bash [ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \ -H "authorization: Bearer $BRIEFKIN_TOKEN" \ -H "content-type: application/json" \ -d @- <<'JSON' { "v": 1, "event_id": "vercel-failed-deployments/", "item_key": "vercel-failed-deployments", "project": "acme-web", "source": "Vercel failed deployments alert skill", "kind": "action", "title": "Production build failed on a type error", "summary": "The 14:05 production build of `main` (`a41c9e2`) failed in `next build`. Production still serves the 11:20 deployment. Two preview failures were fixed by later pushes.", "action": { "request": "It is a type error, so a plain redeploy will fail again. Open the log, or redeploy anyway?", "options": [ "Show me the build log", "Redeploy anyway", "I am on it", "Ignore" ] }, "widget": [ { "type": "Log", "props": { "lines": [ { "time": "14:06", "text": "Running \"next build\"", "level": "info" }, { "time": "14:07", "text": "./app/settings/page.tsx:42:7", "level": "error" }, { "time": "14:07", "text": "Type error: Property 'plan' does not exist on type 'Org'.", "level": "error" }, { "time": "14:07", "text": "Error: Command \"next build\" exited with 1", "level": "error" } ] } }, { "type": "Table", "props": { "columns": [ "Deployment", "Target", "Branch", "Status" ], "rows": [ [ "acme-web 14:05", "Production", "main", "Failing" ], [ "acme-web 10:42", "Preview", "feat/org-plans", "Fixed at 11:03" ], [ "acme-docs 09:15", "Preview", "docs/sso", "Fixed at 09:31" ] ] } } ] } JSON ``` Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report. ## Run it on a schedule Suggested: Weekdays at 9:00, 13:00 and 17:00 (`0 9,13,17 * * 1-5`). From cron, with the agent signed in on that machine: ```bash 0 9,13,17 * * 1-5 claude -p "Run the vercel-failed-deployments skill" # Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run ``` Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/vercel-failed-deployments#schedule Source: https://briefkin.dev/skills/vercel-failed-deployments