Weekly
Get a Friday log of this week's deployments
At the end of the week you see every deployment in the project with its status, plus a count of how many succeeded and failed.
- Runs
- Weekly
- Apps
- Railway
- AI
- Not needed
- Access
- workspace or project token (read)
Send this to your assistant
Create a ClickRuntime automation: every Friday at 5pm, email me this week's Railway deployments in my project, grouped by service, with their status and a count of failures.
First time? Adding ClickRuntime to your assistant takes about two minutes.
Why use it
Why teams use this automation
A developer or small team running several services on Railway pushes changes often, and failures hide in the noise. A deploy that failed at 11pm on a Wednesday may be fixed by a later one, leaving no trace except in the deployments tab of each service. When a customer asks why something broke last week, nobody can say what was deployed or when.
Each week, ClickRuntime queries the deployments for every service in your project, keeps the last seven days, counts them by status and emails you a log. You see how many deploys succeeded, failed or crashed for each service, with the times, so patterns like repeated failures on one service stand out.
It suits teams without a formal release tracker, and solo developers who want a weekly record of what shipped.
What you get out of it
A written history of what shipped
When a bug report mentions last Tuesday, you can check what was deployed that day. Without a log, answering requires opening each service and scrolling its deployment history. It also gives you something to show a client asking for details.
Failure patterns become visible
Four failed deploys on the same service in one week suggest a flaky build step or a bad environment variable. The counts per service bring that to your attention before it becomes a habit.
Release cadence is measurable
Seeing deploys per service per week shows whether you ship daily or sit for days. That helps with planning, and it is useful context when comparing quiet weeks with busy ones. It makes planning more honest.
Handover and review get easier
A teammate returning from leave reads one email to catch up on what changed. A weekly retrospective can start from the log instead of from people trying to recall events.
Unused services get noticed
A service with zero deploys for weeks might be abandoned but still costing money. The log lists every service, including quiet ones, so forgotten projects are easy to spot. Cleaning those up lowers your bill.
How it works
What happens, step by step
Every Friday, ClickRuntime pulls the deployments for each service in your Railway project.
It keeps the ones from the last seven days and counts how many succeeded and how many failed.
You get one email grouped by service, listing each deployment's time and status, with the totals included.
Before it runs live
- Connect Railway
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
- 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 Railway steps into one automation
Under the hood
The code that runs this automation
from collections import defaultdict
from datetime import datetime, timedelta, timezone
from clickruntime import on_trigger, credentials, http, notify
PROJECT_ID = "proj-id"
@on_trigger
def run(event):
query = ('{ deployments(first: 100, input: {projectId: "%s"}) '
'{ edges { node { status createdAt service { name } } } } }') % PROJECT_ID
resp = http.post("https://backboard.railway.com/graphql/v2", json={"query": query},
headers={"Authorization": f"Bearer {credentials.secret('RAILWAY_TOKEN')}"})
resp.raise_for_status()
since = (datetime.now(timezone.utc) - timedelta(days=7)).isoformat()
by_service, failures = defaultdict(list), 0
for e in resp.json()["data"]["deployments"]["edges"]:
d = e["node"]
if d["createdAt"] >= since:
by_service[d["service"]["name"]].append(f" {d['createdAt'][:16]} {d['status']}")
failures += d["status"] in ("FAILED", "CRASHED")
lines = []
for name, rows in sorted(by_service.items()):
lines += [name] + rows
notify.email_me(f"Railway deploys this week ({failures} failed)", "\n".join(lines) or "No deployments.")
return {"services": len(by_service), "failures": failures}FAQ
Common questions
Which deployment statuses are counted?
Does it cover all environments in a project?
Can I see who triggered each deployment?
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
See your estimated Railway spend each week
Every Monday you get an email with each project's estimated usage so far this month.
See how it worksRestart a Railway service every night
Your service gets a fresh restart at a quiet hour, and you only hear about it if the restart fails.
See how it worksGet an email when a Railway deploy fails or crashes
As soon as a deployment in your project fails or crashes, an email tells you which service and what happened.
See how it worksKeep exploring
Set up “Get a Friday log of this week's deployments” from your assistant
Copy the prompt above, or connect your assistant first. Free plan, no credit card.