Every 5 minutes
Get failed Render deploys posted to Slack
Within 5 minutes of a build or update failing, the service and deploy show up in your Slack channel.
- Runs
- Every 5 minutes
- Apps
- Render
- AI
- Not needed
- Access
- read (the key has full access)
Send this to your assistant
Create a ClickRuntime automation: every 5 minutes check my Render services and post to #deploys in Slack when a deploy fails, with the service name, commit message and a link to the deploy.
First time? Adding ClickRuntime to your assistant takes about two minutes.
Why use it
Why teams use this automation
A push to main triggers an automatic deploy on Render, the build fails because of a missing dependency, and the previous version keeps running. Everything looks normal to users, so nobody notices that the fix someone pushed this afternoon never went live. The mistake is discovered the next day when a customer reports the bug again.
Every 5 minutes, ClickRuntime lists your Render services, checks the latest deploy for each, keeps those with a status of build_failed or update_failed, and posts them to Slack with the service name and a link. It remembers what it already reported, so a single failure is announced once.
It suits any team that deploys automatically on push and wants failures to be visible to the people who caused them, soon after they happen.
What you get out of it
Developers learn within minutes
A failed build reported five minutes after the push reaches the author while the change is still in their head. Fixing it then takes far less effort than after a context switch.
Silent failures stop hiding
Because the old version keeps serving traffic, a failed deploy can look like success. The alert makes it clear that the latest change is not live, which prevents false confidence.
Teams share responsibility
A failure in a shared channel is visible to everyone. Colleagues can help or take over if the author is away, and nobody is left unaware of a blocked release. Nobody is left guessing why a release is stuck.
Customer-facing fixes land on time
When a deploy carries an urgent fix, knowing at once that it failed is the difference between a quick retry and a customer waiting another day for a correction. A quick retry saves a day.
Reduced time watching dashboards
Developers no longer need to watch the Render dashboard after each push. They can move on knowing they will hear about a problem, which keeps focus on the next task.
How it works
What happens, step by step
Every five minutes ClickRuntime checks the latest deploys of each of your Render services.
It keeps only deploys where the build or update failed, and skips any it has already posted.
Your Slack channel gets the service, the reason, the commit message and a link to the deploy.
Before it runs live
- Connect Render
What you get
Build your own
Need it to work differently?
Your own rules
Conditions, thresholds, filters and exceptions, written the way you'd explain them to a colleague.
Any number of apps
One automation can read from one app and update several others. Over 248 apps are ready, and anything with an API works too.
AI where it helps
Summaries, classification, extraction and drafts use ClickRuntime's built-in AI, with no extra key.
On a schedule or on each event
Runs as often as every 5 minutes, or the moment an app sends an event, and keeps track of what it already handled.
Changes you can ask for
- Act only on the items that match your own rules, and skip the rest
- Add an AI step, for example to summarize, sort or draft a reply
- Add another app, for example also send it to Slack
- Combine it with other Render steps into one automation
Under the hood
The code that runs this automation
from clickruntime import on_trigger, credentials, http, notify, state, report_fetched
RENDER = "https://api.render.com/v1"
def render(path, **params):
resp = http.get(f"{RENDER}{path}", params=params, headers={"Authorization": f"Bearer {credentials.secret('RENDER_API_KEY')}"})
resp.raise_for_status()
return resp.json()
@on_trigger
def run(event):
seen = set(state.get("seen") or [])
failed = []
for item in render("/services", limit=100):
svc = item["service"]
for d in render(f"/services/{svc['id']}/deploys", limit=5):
dep = d["deploy"]
if dep["status"] in ("build_failed", "update_failed") and dep["id"] not in seen:
failed.append((svc, dep))
report_fetched(len(failed))
if not failed:
return {"failed": 0}
for svc, dep in failed:
notify.slack(f"Deploy failed: {svc['name']} ({dep['status']})\n{(dep.get('commit') or {}).get('message', '')}\n"
f"{svc['dashboardUrl']}/deploys/{dep['id']}", channel="#deploys")
state.set("seen", list(seen | {dep["id"] for _, dep in failed})[-500:])
return {"failed": len(failed)}FAQ
Common questions
Why check every 5 minutes instead of using a webhook?
What do build_failed and update_failed mean?
Will I get alerts for preview environments too?
What permissions does it need?
Does it need AI?
How many runs does it use?
Can I change how it works?
Related
You might also like
Get an email when a Render service goes down
When a service fails or turns unhealthy, an email tells you which one so you can look straight away.
See how it worksGet a weekly count of Render deploys
Each Monday you see how many deploys succeeded and failed for each service over the past week.
See how it worksGet warned before a free Render database expires
A week before a free Postgres database's expiry date, you get one email naming it.
See how it worksKeep exploring
Set up “Get failed Render deploys posted to Slack” from your assistant
Copy the prompt above, or connect your assistant first. Free plan, no credit card.