VercelRocket.Chat

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

Vercellist_deployments

List a project's deployments with creation time, state, and target.

Rocket.Chatsend_message

Send a message to a channel.

Step by step

  1. 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.

  2. 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.

  3. 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.