Diagnose failed Render deploys before anyone opens the dashboard

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.