Automation · Operations and reporting

Check on WhatsApp why a Railway service went down and redeploy it

Ask on WhatsApp why your Railway service went down: an AI agent checks status, deployments and logs, and redeploys it if you ask.

Show me this with my own operation See every automation

How do I check why my Railway service went down without opening the dashboard?

You write to your Met "what is wrong with the API?". The Met finds the project on Railway, lists its services and checks the live status of the environment. It brings the service's latest deployments and reads the build and deploy logs to tell you at which step it failed and with which error. If you ask it to redeploy, and the admin turned that action on in Connections (it starts turned off), it redeploys the service and then checks the status again to tell you whether it is back up. Up to that last step everything is read-only; redeploying is the only write in this procedure.

What starts it

When someone asks for it

It starts when someone on the team asks the Met on WhatsApp why a service is down or failing. Each check runs on request; the Met does not watch the services on its own.

A manual task: someone on the team runs it with a button, or asks the Met for it in chat.

Who runs it

Internal Met that checks your Railway services

This is not a named, seeded Met. It is an internal Met with Railway connected, for the owner or the agency that maintains the app: its work ends when it tells you why the service failed or, if you asked, when it redeployed it and checked its status.

Run by the data analyst Met

Channels: WhatsApp

What you need connected

Railway Automate and collaborate

5 steps · 6 tools

The procedure, step by step

Each step shows the tool that runs. They belong to the real connector: if one of them stopped existing, this page would not build.

1
Find the project

The Met lists the Railway projects the connection can access and takes your app's. It only sees the projects chosen when authorizing.
- list_projects Railway
2
Find the service and its status

The Met lists the project's services, finds the one you named and checks the live status of the environment where it runs.
- list_services Railway
- get_status Railway
3
Check the latest deployments

The Met lists the service's deployments to see which one is the latest, whether it finished or failed, and since when.
- list_deployments Railway
4
Read the failure logs

The Met pulls the service's build and deploy logs, and the HTTP ones if the service gets traffic, and tells you at which step it failed and with which error message.
- get_logs Railway
5
Redeploy if you ask

Redeploying starts turned off. If you ask it to redeploy and the admin turned the action on in Connections, the Met redeploys the service and checks the environment status again to tell you whether it is back up. This step writes to Railway.
- redeploy Railway
- get_status Railway

Before you start

What you need ready

The Met solves none of these for you. If one is missing, the automation stops there.

Railway connected in Met

In Met, open Connections → Railway → Connect, sign in to Railway and choose the workspaces and projects the Met can see.
Redeploy on, if you want it

The redeploy action starts turned off; the admin turns it on in Connections. If you prefer the Met to only diagnose, they leave it off and the procedure ends at the logs.
An internal Met on WhatsApp

Assign the connector to a Met that only serves the team, not the one that talks to customers, because the connection deploys in your Railway account.

The limits

What this automation does NOT solve

Better said here than discovered halfway through the rollout.

It does not fix the code. If the deploy fails because of an error in your app, redeploying repeats it; the Met tells you which error it sees, and fixing it is the team's work.
It does not ask for confirmation in the chat before redeploying. If the admin turned the action on, since it starts turned off, the Met runs it when you ask; if you do not want it to, they leave it off in Connections.
It does not alert you on its own when a service goes down. The check starts when someone asks the Met; this procedure does not schedule monitoring.
It does not delete services or change their settings. This procedure does not use Railway's agent, which can apply configuration changes on your behalf.

FAQ

Questions about this automation

Yes, the ones you chose when authorizing. It helps to write in the Met's instructions which project and service belong to each app so it does not check the wrong one.

Because Railway's agent takes the whole request and can apply changes on its own. This procedure prefers steps you can see one by one and that, except for redeploying, only read.

The Met tells you the service is still failing and shows you the error from the new deploy's logs. From there, the fix belongs to the team that maintains the app.

Keep going