Auto-triage Railway deploy failures into Linear tickets

Build me an agent workflow that triages Railway deployment failures and files a Linear ticket for whoever broke it.

Trigger: a Railway outgoing webhook configured for the Deployment.failed event. Use the webhook payload directly. I care about these fields: deploymentId, serviceName, environmentName, projectName, status, commit (SHA), author (committer username/email), and branch. Railway webhook docs: https://docs.railway.com/guides/webhooks.

When the webhook fires, the agent should:

1. Pull deploy context from Railway. Call Get Deployment with deploymentId to confirm the status and grab the Railway deploy URL. Then call Get Build Logs and Get Deployment Logs for that deployment to capture both build-time and runtime output. Keep the last ~200 relevant lines (errors, stack traces, the failing step) and drop noise.

2. Identify the breaking change on GitHub. Use the repo owner/name configured for the workflow plus the branch and commit SHA from the webhook. Call Get a Pull Request if the deploy traces to a merged PR (look it up by commit SHA via Search Issues and Pull Requests, or fall back to List Pull Requests filtered by head branch). Capture the PR title, body, author, and changed files. If no PR is found (direct push), just use the commit author from the webhook.

3. Produce a short root-cause summary (no more than ~6 lines). Classify the failure as build error vs runtime error, name the exact failing step or command, quote the key error message, and call out a suspected file or area based on the changed files in the PR. Keep it tight and skimmable.

4. File the ticket in Linear. Call Create Issue in the team I configure (default: the Engineering team). Title: "[Deploy failure] <serviceName> on <branch> — <one-line cause>". Description: the root-cause summary, the trimmed log excerpt in a code block, the list of changed files, and direct links to the Railway deployment URL and the GitHub PR/commit. Priority: Urgent. Assignee: the Linear user matching the commit author's GitHub username or email; if no match, leave unassigned and add a comment tagging a configured fallback assignee.

5. Post one Slack alert. Call Send a Message into #deploys (configurable). The message should include: the service name and environment, a one-line cause, the commit author, a link to the Linear issue that was just created, and a link to the Railway deployment. Use a single message, not a thread of follow-ups.

Guardrails: if Get Deployment shows the deploy has since recovered (e.g. a retry succeeded) before the agent finishes, skip Linear and Slack and exit. If the same commit already has an open Linear issue with the "deploy-failure" label, add a comment to that issue instead of creating a duplicate, and still post the Slack alert linking to the existing issue. Tag the new Linear issue with the label "deploy-failure" so future runs can find it.

Inputs the workflow should expose for configuration: GitHub repo (owner/name), default Linear team, default Linear assignee fallback, Slack channel, and an optional environment filter so users can limit this to production only.

Additional information

What does this prompt do?

Watches Railway and reacts the moment a deployment fails, with no manual log digging.
Reads the build and runtime logs to figure out whether the deploy broke at build time or at startup, and pinpoints the failing step.
Looks up the commit and pull request that triggered the failed deploy, so the right person gets the ticket.
Opens an urgent Linear issue assigned to the author, with a plain-English summary and direct links back to Railway and GitHub.
Posts a single Slack message in your deploys channel so the whole team sees the failure and the ticket link at once.

What do I need to use this?

A Railway account where you can add an outgoing webhook for failed deployments.
A GitHub login with access to the repository that Railway deploys from.
A Linear workspace and a team where new bug tickets should land.
A Slack workspace and the channel you want failure alerts to go to.

How can I customize it?

Change the Slack channel from #deploys to whatever your team actually watches, or send a direct message to your on-call instead.
Adjust the priority and labels on the Linear ticket, for example mark staging failures as Medium and production failures as Urgent.
Narrow it to specific services or environments if you only want alerts for production deploys.
Add extra context to the ticket, like recent environment variable changes or the previous successful deploy, before it gets filed.

Frequently asked questions

Does this work if I deploy multiple services from the same Railway project?

Yes. The agent reads the service name and environment from the Railway event, so failures in different services land as separate tickets with the right context.

What if the author of the breaking commit is not on my Linear team?

You can tell the agent to fall back to a default assignee, like the on-call engineer or a triage queue, when the commit author cannot be matched to a Linear user.

Will it spam Linear if the same deploy retries and fails again?

You can ask the agent to check for an open ticket for the same commit or deploy first, and add a comment instead of creating a duplicate.

Can I send the alert somewhere other than Slack?

Yes. Swap the Slack step for an email, a Microsoft Teams message, or a Discord post and the rest of the flow stays the same.

Do I have to use Linear for the ticket?

No. The same flow works with Jira, GitHub Issues, or Asana. Just tell the prompt which tracker to file in and how to map priority.