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

a month 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

a month 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 about 1 month ago


Status changed to Solved stephenrosario-0117 about 1 month ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...