Post failed Vercel deployments to Rocket.Chat
A Vercel + Rocket.Chat agent flow
The preview link in a pull request is only as good as the build behind it, and a build that errored shows green in the PR until someone clicks through. For a team running its own Rocket.Chat, the fix is to have the failure announced where the conversation already is. This recipe handles that. The agent calls list_deployments for each project, reads the state on the recent ones, and when a deployment comes back ERROR it posts to a Rocket.Chat channel with send_message: the project, the target (production or preview), the branch, and the deployment URL. Vercel answers the request rather than pushing, so the agent polls on a cadence and remembers the last deployment id per project, so a broken build is announced once.
The flow
list_deploymentsList a project's deployments with creation time, state, and target.
send_messageSend a message to a channel.
Step by step
- List recent deployments
The agent calls list_deployments for each project. Each entry has a creation time, a state (BUILDING, READY, ERROR, CANCELED), and a target marking it production or preview.
- Catch the failures
Track the last deployment id you posted per project. A deployment in the ERROR state with an id you haven't seen is a new failure; READY and BUILDING are skipped. One failed build, one message.
- Post to Rocket.Chat
For each new failure the agent calls send_message with the channel and a short line: project, target, branch, and the deployment URL. Production failures can route to a louder channel than preview ones if you split them by target.
Tell your agent
Every two minutes, call Vercel list_deployments for my projects, and for any deployment in the ERROR state I have not posted before, send the project, target, branch, and deployment URL to the #deploys Rocket.Chat channel.
Setup
This flow needs both servers connected to your agent. Follow each install guide:
Worth knowing
- list_deployments returns metadata and state, not the reason a build failed; follow up with get_deployment_build_logs by id if you want the agent to include the failing step in the message.
- Both production and preview deployments come back in the same list. Read the target field and decide whether preview failures deserve a ping, or a busy PR queue floods the channel.
Questions
- Can it announce only production failures?
- Yes. Filter on the target field and post only when it marks production, so preview build noise from open pull requests stays out of the channel.
- Does it cover runtime errors after a deploy goes live?
- No, list_deployments reflects build outcomes. For errors in a running deployment pair it with get_runtime_logs so the agent can also watch a deployment that built fine but throws at request time.