Postgres service in crash loop after May 19 outage — catatonit exec failure
stephenrosario-0117
HOBBYOP

25 days ago

Hi Railway team,

My Postgres service has been in a crash loop since your May 19

edge network / Google Cloud outage and cannot be recovered through

the dashboard.

== Timeline ==

  • 2026-05-19 22:17:15 UTC: Postgres received a fast shutdown signal

    (clean shutdown logged, checkpoint completed, "database system

    is shut down")

  • Approximately concurrent with the start of your May 19 service

    disruption

  • Every restart attempt since has failed with the same error pattern

== Error pattern ==

Container init fails immediately on every start attempt:

Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/

ef7722e4-aa18-4188-adcd-32a681a31b02/vol_ui7jgixtkygtx1rk

ERROR (catatonit:2): failed to exec pid1: No such file or directory

The volume mounts successfully, but the container init never starts.

Same error on every restart — this is reproducible, not transient.

== What I've tried ==

  • Multiple manual restarts from the dashboard
  • All produce the same catatonit exec failure
  • No options in the dashboard to redeploy or rebuild the service image

== Status ==

  • Service: Postgres (crashed)
  • Web service in same project: Online (healthy, but cannot reach DB)
  • Volume: postgres-volume — mounting fine, data should be intact

== Request ==

I need help recovering the Postgres service. Please do not delete

the volume — data preservation is critical.

This appears to be a side effect of the May 19 outage leaving the

container image in a bad state. The catatonit exec failure suggests

the image's init binary is missing or unreadable post-incident.

== Project details ==

Service: Postgres

Plan: Hobby

Let me know what other information you need.

Thanks,

Stephen

Solved

1 Replies

Railway
BOT

25 days ago

We confirmed your Postgres service is crash-looping with the container init failure you described, which is caused by a stale container image after the disruption. Your volume data is intact - this error occurs before the database process starts, so no data was affected. To fix this, open the command palette with Cmd+K (or Ctrl+K) and select "Redeploy source image" - this re-pulls a fresh copy of the Postgres image, which is different from the normal restart or redeploy options in the 3-dot menu (those reuse the cached image, which is why they keep producing the same error).


Status changed to Awaiting User Response Railway 25 days ago


Status changed to Solved stephenrosario-0117 25 days ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...