# Diagnose failed Render deploys before anyone opens the dashboard

> The moment a Render deploy fails, get a Slack post naming the likely cause, the commit and author behind it, and the last deploy that worked.

- Workflow type: agent
- Services: Render, GitHub, Slack, Linear
- Categories: Engineering
- Published: 2026-08-09

## What it does

- Watches your Render services and reacts the moment a build, pre-deploy, or deploy step ends in failure.
- Reads the build output and works out the actual cause, such as a dependency that would not install, a broken build script, a migration that errored, or a build that ran out of memory.
- Names the commit that broke it and the teammate whose pull request carried it, quoting only the two or three log lines that prove the diagnosis.
- Posts the write-up to Slack alongside the last deploy that ran cleanly as a rollback candidate, and opens a Linear ticket only when the same service fails twice in a row.

## What you'll need

- A Render account with the services you want watched.
- A Slack workspace and the channel where the team should get the diagnosis.
- A GitHub account with access to the repository behind the service, so the workflow can find the pull request and its author.
- A Linear workspace and the team that should receive tickets for repeat failures.

## Prompt

When a deploy fails on Render, I want an agent to work out why before anyone opens the dashboard. Trigger this workflow from a Render webhook and act on the deploy lifecycle completion events: deploy_ended, build_ended, and pre_deploy_ended. The Render webhook payload carries type, timestamp, data.id, data.serviceId, data.serviceName, and data.status, where status is included on completion events and is one of succeeded, failed, or canceled. Only continue when data.status is failed. Stop quietly for succeeded and canceled, and for any other event type.

Identify the deploy. Use the deploy id from the webhook payload when one is present. If it is not, call Render's List deploys for data.serviceId and take the most recent deploy. Then call Render's Retrieve deploy for that service and deploy to get the failing commit id and commit message, the terminal status (build_failed, update_failed, or pre_deploy_failed), and the start and finish timestamps.

Pull the build output with Render's List logs, scoped to the failing service and to a single bounded time window around the failure, roughly from the deploy's start timestamp to the webhook timestamp. Read one window only. Render's log retrieval is rate limited to about 30 requests per minute, so do not page endlessly. If the first window comes back truncated, narrow it toward the end of the deploy where the error actually lands rather than fetching page after page.

Find who shipped the change. Take the commit id from the Render deploy object and use GitHub's Search Issues and Pull Requests to find the pull request that carried that commit, searching for the commit id across pull requests in the repository behind the service. Report the pull request number, title, and author. Do not try to fetch the commit from GitHub directly. The commit id and message come from Render's own deploy object, and GitHub is used only to search pull requests. If no pull request matches, say the commit was most likely pushed directly and fall back to the commit message alone rather than naming someone by guesswork.

Classify the failure into a concrete cause rather than restating the status. Typical causes are a dependency install error (a package failed to resolve, a lockfile is out of sync, a private registry rejected credentials), a build script error (a compile or type error, a missing or misconfigured build command, a test failing inside the build), a failed migration (a database migration errored during the pre-deploy step), and an out of memory build (the builder was killed, heap exhaustion, exit code 137). Quote the two or three decisive log lines verbatim as the evidence for the call you made. Do not dump the whole log.

Name a rollback candidate. Use Render's List deploys for the same service and find the most recent deploy that reached live status. Report its deploy id, its commit id, and when it went live, and present it as the last known good deploy. Do not roll anything back automatically; this is a recommendation for a human to act on.

Post the diagnosis to Slack with Send a Message, to the engineering channel I pick. Lead with the service name and the one-line cause, then the failing commit and its message, the pull request and its author, the two or three quoted log lines, and the rollback candidate. Keep it tight enough to read on a phone.

Only create a Linear issue when the same service has failed twice in a row, so a single flaky build does not generate a ticket. Decide this from the same List deploys history: if the completed deploy immediately before this one, for the same service, also ended in a failed terminal status (build_failed, update_failed, or pre_deploy_failed), then use Linear's Create Issue to open a ticket titled with the service name and the diagnosed cause, with the full diagnosis, both failing commits, and the rollback candidate in the description. On a first failure, post to Slack only and note in the message that no ticket was opened yet.

## How to customize

- Change which Slack channel gets the diagnosis, or route different services to different channels.
- Loosen or tighten when a ticket gets created, for example on the first failure instead of the second, or only for production services.
- Adjust how much of the build output the write-up quotes, and which failure causes get called out by name.

## Example output

api-gateway: build failed

Cause: the build ran out of memory. The bundler was killed partway through, so the image never finished.

Commit: 4f2a91c "bump chart library to v6"
Pull request: #812, opened by Priya Raman

Decisive log lines:
  FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
  error Command failed with exit code 137.

Rollback candidate: the deploy on commit 9b1e440, live since 3 hours ago.

This is the first failure in a row for api-gateway, so no Linear ticket was created.

## FAQ

### Will this roll back the broken deploy for me?

No. It finds the last deploy that ran cleanly and names it as a rollback candidate, so the option is ready and waiting, but the decision and the click stay with you.

### What happens when a deploy is cancelled rather than failed?

Nothing. The workflow only reacts to genuine failures, so cancelled and successful deploys pass by silently and your channel stays quiet.

### Why does it wait for two failures before creating a ticket?

Because builds fail for flaky reasons all the time. Waiting for a second failure in a row on the same service means you get a ticket for real problems instead of one for every hiccup.

### What if the commit was pushed straight to the branch with no pull request?

The write-up still names the commit and its message, and simply notes that no pull request was found so nobody gets blamed by guesswork.

### Can it watch more than one service?

Yes. It reacts to failures from any Render service you have connected, and you can narrow it down to just the services you care about.

Use this prompt in General Input: https://www.generalinput.com/prompts/diagnose-failed-render-deploys-before-anyone-opens-the-dashboard