Triage failed Vercel deploys into GitHub issues and Slack

I want an agent workflow that triages failed Vercel deployments so build errors do not just sit in the dashboard. Trigger: an incoming webhook from Vercel for the deployment.error event. Set up the workflow to receive that webhook payload and run on every failure.

When the webhook fires, pull the deployment id from the payload, then use Vercel's Get Deployment Events operation to fetch the build logs and Vercel's Get Deployment operation to grab the project name, branch, commit SHA, commit message, and commit author. From the build events, extract the lines that actually explain the failure. Trim aggressively: keep the last roughly 200 lines plus any line containing 'Error', 'error:', 'failed', or a stack trace. TypeScript errors, missing environment variables, install failures, lockfile mismatches, and OOM kills are the common patterns to look for.

Then write a concise root-cause summary in plain English (one or two sentences) plus a suggested fix (one or two sentences). Reference the specific file, line, package, or env var when the logs make that possible.

Next, use GitHub's Create an Issue operation to open an issue in the repository linked to the Vercel project. The issue title should include the project name and a short error summary, for example 'Vercel build failed on main: missing NEXT_PUBLIC_API_URL'. The issue body should contain the root-cause summary, the suggested fix, the trimmed log excerpt inside a fenced code block, the branch and commit SHA with a link to the commit on GitHub, the commit author, and a link back to the failed deployment on Vercel. Apply a 'deploy-failure' label and assign the commit author when they have a GitHub handle on file.

Finally, use Slack Bot's Send a Message operation to post a short alert into the team's engineering channel (make the channel configurable). The Slack message should be one or two lines: the project, branch, the one-sentence root cause, and two links, one to the failed Vercel deployment and one to the new GitHub issue. Keep it scannable. Do not paste the full log into Slack.

Suppress noise with a configurable filter: skip deployments on stale branches (no open pull request, or branch deleted), skip branches whose names match a configurable ignore list (for example 'dependabot/*', 'renovate/*'), and skip projects in a known-flaky list. If the same commit SHA fails again within an hour, update the existing GitHub issue with a comment and reply in the original Slack thread instead of opening a new issue and posting a new alert.

Inputs the user should configure when setting this up: the Slack channel name or id for alerts, the GitHub owner/repo to file issues into (or a map from Vercel project name to repo), the list of branch patterns to ignore, the list of project names to ignore, and the issue labels and default assignee.