I have always been a Railway supporter. I recommended it to others and built my production apps on it. But the situation is reaching a point I can no longer accept: build failures have become a constant, not an occasional hiccup.

Today (Oct 26) a routine merge to main triggered deploys for four services in our EU West production environment. Three of them failed during the build stage, and the fourth was still building when I checked:

frontend: failed right after “All aboard, next stop: builder v4”. No build step ran.

cron: failed with Build Failed: build daemon returned an error < failed to solve: frontend grpc server closed unexpectedly >.

worker: built and pushed its image fine, then was still marked FAILED.

api: still building several minutes later.

The same commit passes our CI (typecheck, build and the full test suite), so this is not a code problem. It matches the open incident “Builds (EU West): sustained elevated latency, some builds may fail early” (status.railway.com/incident/QORAHHDA), which has been open since 11:30 UTC.

This is not a one-off. It keeps happening, again and again, and every time it leaves our services half-deployed: the api can end up on the new version while the frontend stays on the old one. For a production app with real users, that skew is the real risk, not the delay.

Billing, by contrast, never has an outage.

Builds fail, but billing works perfectly. I was charged on time as usual. And on top of all these problems, what I received was not a credit, a refund or even an acknowledgement, but an incorrect invoice. I moved my X project to another workspace, yet its invoice was still issued to the original workspace. The project lives in one place and the bill goes to another. If billing can follow a project that has already moved, the build pipeline should be at least as reliable.

Requests:

A failed build should retry automatically when the cause is on Railway’s side (builder or storage), not in the user’s code.

Offer an option to deploy a group of services atomically, so that if one fails to build, none of them switch to the new version.

Say “infrastructure error” clearly in the deployment status, so we don’t have to dig through build logs to find out it wasn’t our fault.

Share a postmortem and a capacity plan for EU West storage. This keeps happening.

When a project is moved to another workspace, its usage should be billed to the new workspace from the moment of the move, and the invoice should say which workspace and period it covers.

Please correct the invoice for the Adhelm project and credit the original workspace.

Give some credit for the deploy minutes lost to failures caused by Railway’s own infrastructure.

Running deployments stayed up, and we appreciate that. But a failed build is the moment of truth for a deploy pipeline, and right now that is where reliability breaks down. I want to keep recommending Railway, but that depends on these problems being fixed.