Weekly

Get a weekly count of Render deploys

Each Monday you see how many deploys succeeded and failed for each service over the past week.

Runs: Weekly
Apps: Render
AI: Not needed
Access: read

Send this to your assistant

Create a ClickRuntime automation: every Monday at 9am email me a table of my Render services with how many deploys succeeded and how many failed in the last 7 days.

Paste it into your assistant. It tells you what it will send or change before it runs live.

Add to ChatGPT Add to Claude

First time? Adding ClickRuntime to your assistant takes about two minutes.

Why use it

Why teams use this automation

A team running several services on Render deploys many times a week, and each service has its own events page. When the engineering lead is asked how stable releases have been, the answer is a guess: they open each service, scroll the deploy list and count failures by eye. Trends in failed builds go unnoticed until someone is frustrated.

Each week, ClickRuntime lists the deploys for every service on your Render account for the last seven days, tallies them by outcome and emails you a summary showing how many deploys each service had and how many failed. A service with an unusual number of failures is easy to spot in the table.

It is useful for engineering managers, tech leads and solo developers who want a regular read on release health without opening each service.

What you get out of it

Release stability is measured, not guessed
Counting failures per service gives you a number to track. A service going from one failed deploy a week to five is a clear signal that something in its pipeline changed.
Noisy services get attention
If one service accounts for most failures, you know where to spend engineering effort. Fixing a flaky build step for that service improves the whole team's experience. Effort goes where it reduces the most pain.
Retrospectives have data
A weekly summary gives a team material for a short review. Instead of recalling events from memory, people look at which services deployed most and which struggled. Teams stop arguing from memory.
Deploy frequency is visible
The number of deploys per service shows how often you really ship. Teams aiming for smaller, more frequent releases can see whether they are getting there. Progress toward smaller releases can be tracked.
Idle services stand out
A service with no deploys in weeks may be abandoned or neglected. Seeing the zero in the table prompts a decision to maintain, update or shut it down. Unused services cost money while they sit there.

How it works

What happens, step by step

Every Monday ClickRuntime gets the last seven days of deploys for each of your Render services.
It counts how many succeeded and how many failed per service.
The table arrives in your inbox.

Before it runs live

Connect Render

What you get

RunsWeekly

Get a weekly count of Render deploystoday, 9:00Succeeded

Email · Weekly deploysservice | succeeded | failed api-server | 14 | 1 worker | 6 | 0

Build your own

Need it to work differently?

This template is a starting point. Copy the prompt and change it, or describe a different automation from scratch, with your own conditions, more apps or an AI step. Your assistant writes it, tests it and runs it on ClickRuntime.

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

Run it at a different time, more or less often, or only on weekdays
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

This is the Python script that runs each time the automation starts. Your AI assistant writes it for you when you send the prompt, and you allow each step in your assistant. To change how the automation works, describe the change to your assistant and it updates the script for you. For every function it can use, see the script reference.

get_a_weekly_deploy_summary.pyexample

from datetime import datetime, timedelta, timezone
from clickruntime import on_trigger, credentials, http, notify

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):
    since = (datetime.now(timezone.utc) - timedelta(days=7)).isoformat()
    rows = ["service | succeeded | failed"]
    for item in render("/services", limit=100):
        svc = item["service"]
        deploys = [d["deploy"] for d in render(f"/services/{svc['id']}/deploys", limit=100, createdAfter=since)]
        ok = sum(d["status"] == "live" or d["status"] == "deactivated" for d in deploys)
        bad = sum(d["status"] in ("build_failed", "update_failed") for d in deploys)
        rows.append(f"{svc['name']} | {ok} | {bad}")
    notify.email_me("Render deploys last week", "\n".join(rows))
    return {"services": len(rows) - 1}

FAQ

Common questions

Which deploy outcomes are counted?

Render records statuses such as live, build_failed, update_failed, canceled and deactivated. The summary counts successful ones and failures separately, so you can see how many releases went out and how many did not. Canceled deploys are shown on their own line.

Does it include all services in my Render account?

It covers the services your API key can see, which means all those in the workspace that the key belongs to. Static sites, web services, workers and cron jobs are all included. You can exclude any that are not worth tracking.

Can I see which commit caused a failure?

Render attaches commit information to each deploy, and the summary can list the commit message for failed deploys. That lets the team jump to the change that broke the build, instead of searching through deploy logs.

What permissions does it need?

read. Nothing else in your accounts is used.

Does it need AI?

No. It runs without AI, so it doesn't use your plan's AI allowance.

How many runs does it use?

One run each time it runs (weekly). Checks that find nothing to do and stop right away aren't counted.

Can I change how it works?

Yes. Describe the change to your AI assistant, for example a different schedule, channel or filter. It updates the automation, tests it and tells you what changed.

Daily