20 days ago
Hello,
Since the outage few weeks ago, I've some problems with this application. Whenever I make changes and push it to master, a new deployment is started automatically. When the deployment is finished, I only see the label "Starting container". There is no other logs than that. After several times executing the deploy function, the service get back online again. I tried to ask the AI to solve the problem, but it provides unrelated things for this service.
I assume something went wrong with the outages and that's why I am getting these errors. Can you double check it?
3 Replies
20 days ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 20 days ago
20 days ago
I've tried another region, but then everything worked very slow so I had to set it back. On both regions it works at first, but now (after completely deleting and recreating in the same region) the issue still persists
20 days ago
There genuinely was a major Railway-wide outage about four weeks ago, on May 19-20, 2026, when Google Cloud's automated systems mistakenly suspended Railway's production account, taking down all running Railway services for roughly eight hours. On top of that, the status history shows a string of smaller, more recent issues too: deployments being slow to go out on June 11, degraded performance in US West and Singapore the same day, GitHub API authentication issues on June 10, builds taking longer than usual on June 9, and build failures/delays and metrics/logs delays in early June. So "since the outage a few weeks ago I've had problems" lines up with a real pattern, not just bad luck — Railway's infra has been visibly shaky since that incident, including logging/metrics pipeline issues, which would explain exactly the symptom you're seeing (no logs showing up beyond "Starting container").
What I can say is that "container starts, produces no logs, hangs, and then resolves itself after repeated manual redeploys" is a classic symptom of either (a) the platform's logging pipeline being degraded so your service may actually be starting fine but its output isn't reaching you, or (b) the underlying host/node your container lands on being unhealthy, and retrying just gets you scheduled onto a healthier node.
A few things worth doing on your end:
First, check Railway's status page directly (railway.statuspage.io) for your specific region/component at the time of your failed deploys, and compare timestamps — if there's a logged incident matching your deploy window, that's good evidence it's platform-side rather than your config.
Second, since this is a database/managed service rather than your own app code, check whether you're using a Railway-provided database template/image versus a custom Dockerfile. If it's a Railway template, volume-mount issues (the volume not attaching fast enough, or being on a degraded storage node) are a very common cause of exactly this symptom — container starts, but the DB process inside never gets to its "ready" log line because it's blocked waiting on disk.
Third, when this happens again, check the Railway "Deployments" tab for the metrics graph (CPU/memory/network) for that failed instance, even with no logs — if you see zero CPU/memory activity, that's a strong sign the container is stuck before even reaching your database's entrypoint, which is infra-side starvation, not your config.
Hope this helps