Daily Railway deploy digest in Slack with GitHub PR context

Build me an agent workflow that posts a daily Railway deploy digest into Slack so my engineering team can see what shipped yesterday without scrolling Railway.

Trigger: cron, every weekday (Monday through Friday) at 09:00 America/New_York.

Each run, the agent should do the following:

1. Use Railway's List Projects to enumerate every project the token can see. For each project, use List Environments and pick the environment named "production" (skip preview and ephemeral environments). For each service in that production environment, use List Deployments to get every deployment whose createdAt is within the last 24 hours. Bucket them into successful, failed, and in-progress.

2. For each successful deploy, look at the deployment's meta object for commitHash and prNumber (and the source repo owner/name). If a PR number is present, call GitHub's Get a Pull Request to fetch the PR title, author login, and merged body. Use that to build a one-line "what shipped" entry per service: service name, PR title, author handle, and a link to the PR. If no PR is linked, fall back to the commit message and short SHA.

3. For each failed deploy, use Railway's Get Build Logs to fetch the tail of the build log (last ~50 lines is fine). Have the agent write a single short sentence guessing the cause (for example: "TypeScript compile error in src/server.ts" or "npm install failed: missing peer dep"). Include a link to the Railway deployment URL.

4. For staleness: for every production service across all projects, check the most recent successful deployment. If it is older than 14 days, list the service under a "stale" section with its last-deploy date.

5. Send one Slack message via Send a Message into the channel #engineering (let me change the channel at setup). The message should be structured as three sections, in this order:

• Shipped yesterday: bulleted list of services that successfully deployed, each line showing service name, PR title, author, and a PR link.

• Failed deploys: bulleted list of services where a deploy failed in the last 24 hours, with the cause guess and a link to the Railway deployment.

• Stale services: any service whose last successful production deploy is older than 14 days, with the date.

Constraints:

• One Slack post per run. No thread, no follow-up messages.

• Cap the digest to roughly 15 services. If more shipped, prioritize failures, then stale, then successful, and append a final line like "+ 7 more services shipped".

• If nothing shipped in the last 24 hours, still post a short message saying so, and still include the stale section if there is anything to flag.

• Write the tone like a human release note, not a list of SHAs. Plain English titles, no commit hashes in the main bullets (a SHA fallback is fine only when there is no PR).

Connections needed: Railway (API token from Account Settings), GitHub (read access to the repos behind the Railway services), Slack (workspace plus the destination channel).

Additional information

What does this prompt do?

Posts one Slack message every weekday at 9am Eastern with a clear changelog of what shipped to your Railway production environments yesterday.
Lists each service that shipped successfully with the matching pull request title and author, so the digest reads like a release note instead of a wall of commit hashes.
Flags any failed deploys with a link back to Railway and a short guess at the cause from the tail of the build log.
Calls out any production service that has not shipped in over 14 days as stale, so quiet codepaths do not silently rot.

What do I need to use this?

A Railway account with at least one project and an API token from Account Settings.
A GitHub login with read access to the repositories your Railway services deploy from.
A Slack workspace and a channel like #engineering where the digest should land.

How can I customize it?

Change the schedule. Move the post time, switch to a different timezone, or run it daily including weekends.
Swap the destination channel, or send a separate digest per team channel.
Adjust the staleness threshold from 14 days, change the service cap, or restrict to a specific Railway workspace or project.

Frequently asked questions

Does this only cover production environments?

Yes by default. The digest pulls deploys from each project's production environment and skips preview or ephemeral environments. You can broaden it to include staging or any other named environment when you set it up.

What happens on a day when nothing shipped?

You still get one short Slack message confirming there were no deploys in the last 24 hours, plus the stale-services callout if anything has been quiet for more than 14 days.

How does it match a Railway deploy to a GitHub pull request?

Each Railway deploy carries the commit and pull request reference from the source repository. The workflow uses that to fetch the pull request title, author, and merged description from GitHub so the digest reads like a changelog.

Will the message get too long if we ship a lot?

The digest caps itself at roughly fifteen services per day, prioritizes failures and stale services, and posts as a single message with no thread, so it stays scannable.

Can I send this somewhere other than Slack?

Yes. You can point the same digest at a different Slack channel, a Discord channel, or an email recipient. Slack is the default because it matches how most engineering teams already get release pings.