Same thing here. Also seems that this constant restart loop burned all my credits, at least thats what it says (sometimes), but I can't load my usage site to check that. The whole website is still so laggy and slow.

Apologies for this canned message but in an effort to help all our customers get back up and running, we are sending this bulk message. As you may know, we had a major interruption to our services yesterday. We've published a post-mortem if you'd like more information on the incident. It describes what happened and what we are doing to prevent it in the future. We are deeply sorry for the impact that it has had on you.

It is taking some time to bring everything back up, but we are working on it as fast as we can. In general, a redeployment should fix most service issues. Due to the volume of customers redeploying right now, builds and deploys may take longer than normal to process.

You can track recovery status here: https://status.railway.com/incident/KVZ1Z8GY

If you are still having other issues that might be related to the incident you can read more here: https://station.railway.com/community/road-to-recovery-post-gcp-outage-builds-d362e48c

Feel free to respond if your question has not been addressed.

Thanks — I read the post-mortem and the road-to-recovery thread.

In our case redeploying does NOT recover the service. The Postgres container has been crash-looping for over 10 hours with the same low-level container init error on every restart

and every manual redeploy:

Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/a88dfa0e-cd02-4a92-b368-d3fdbef9aaf5/vol_hihlyoerch3phuhw

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

Postgres itself never starts — only the catatonit init error repeats. The dashboard occasionally flashes "Deployment successful" for a few seconds and then drops back into the

same loop. This does not match the build/deploy slowness described in the recovery thread; it looks like either the volume mount or the underlying container image on the host this

service is currently allocated to is broken at the platform layer.

Details:

• Project: atehra (7c2dbf4e-6dee-47de-81f4-5d4833748baa)
• Environment: production (fe8f7634-7167-4cf8-8337-080162c76a26)
• Service: atehra-db (Postgres)
• Volume: postgres-volume (vol_hihlyoerch3phuhw)
• Region: US East
• Down since: ~22:19 UTC 2026-05-19

To protect data we have NOT recreated/detached the volume and have NOT pointed atehra-api at an alternative database.

Could someone migrate this service to a healthy host so it can remount the existing postgres-volume? We strongly prefer recovering the volume over restoring from a (potentially

stale) backup.

Happy to provide any further logs, IDs, or temporary access. Thank you.

Hey, sorry about the long downtime and the canned responses earlier. Your Postgres is still crash-looping with the catatonit pid1 error, which means the container image that was pulled during the outage is broken.

The fix that's worked for other users hitting this same error: go to your atehra-db service Settings, find the Postgres version, and update it (e.g. if you're on 16, change to 16.8 or 17). This forces a fresh image pull while keeping your existing volume and data intact. Once Postgres is back, redeploy atehra-api and it should reconnect.

Your data is safe on the volume, this only changes the container image, not the volume.

Let us know if that works or if you run into anything else.