Send failed Render deploys to Telegram
A Render + Telegram agent flow
You push to main, walk away, and the deploy fails the build step while you're at lunch. Render emails you, but the email lands in a folder you check twice a day. A Telegram message lands on your phone. This recipe has an agent poll Render and ping you the moment a deploy goes red. It calls list_deploys for each service, reads the status on the most recent deploy, and when that status is build_failed, update_failed, or canceled it sends a Telegram message with send_message: the service name, the deploy status, the commit, and the timestamp. Render answers the call rather than notifying you, so the agent runs on a cadence, every couple of minutes, and remembers the last deploy id per service so a single failure pings once.
The flow
list_deploysLists deploys matching the provided filters; returns all deploys for the service if none are given.
send_messageSends a text message to a chat.
Step by step
- List recent deploys per service
The agent calls list_deploys for each service id, newest first. Each deploy carries a status: created, build_in_progress, live, build_failed, update_failed, canceled, and so on.
- Catch the failures
Track the last deploy id you alerted on for each service. A new deploy whose status is one of the failure states is the trigger; in-progress and live deploys are skipped. This way one failed deploy produces exactly one message.
- Send the Telegram alert
For each new failure the agent calls send_message with the chat id and a compact line: service, status, commit short SHA, and when it failed. A link to the Render deploy can ride along so a tap opens the logs.
Tell your agent
Every two minutes, call Render list_deploys for my web service, and if the latest deploy has a status of build_failed, update_failed, or canceled that you have not already alerted on, send a Telegram message with the service, status, and commit SHA.
Setup
This flow needs both servers connected to your agent. Follow each install guide:
Worth knowing
- list_deploys returns deploys for one service when you pass a filter, or everything when you don't; scope the filter so you aren't paging the whole account each run.
- A deploy moves through several statuses before settling, so alert on the terminal failure states, not on a transient build_in_progress that has not finished yet.
Questions
- Does this catch a service that goes down after a successful deploy?
- No. list_deploys reflects deploy outcomes, not live health. For runtime failures pair it with list_logs or get_metrics so the agent can also watch a healthy service that later starts erroring.
- Can I alert on successful deploys too?
- Yes. Add live to the set of statuses you send on if you want a deploy-finished ping, though most teams keep the channel to failures so it stays quiet until something needs attention.