Hi team,

My Postgres service has been crash-looping since approximately 08:56 GMT+1 on May 20 2026. Symptoms appear identical to the wave of threads posted in the last 15-20 minutes following the pinned "GCP Suspension Outage: May 19th 2026" post (e.g. "Postgres database fails to start - catatonit pid1 error - data recovery needed", "Postgres service crashes immediately: failed to exec pid1", "Production Postgres WAL corrupted after May 19 GCP suspension"). I believe my service is caught up in the same incident.

Description of the issue:

• Postgres deployment ran fine for 2 weeks, then began crash-looping today around 08:56 GMT+1
• Each container start fails within seconds at the init layer
• Downstream Next.js app (assetflow) cannot connect and returns Prisma P1001 "Can't reach database server at postgres.railway.internal:5432"
• Free plan, so no Pro-tier automated backups exist on the volume

Error messages (Postgres deploy logs, tight loop):

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

Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/af5f7e1e-9f76-4d40-ac7c-12052770ba45/vol_mlb1fd7em4gay133

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

[pattern repeats every ~1 second indefinitely]

This indicates catatonit cannot exec the container entrypoint, so Postgres itself never starts and never reads the volume. Given the broader incident, my read is that the underlying issue is volume / WAL state inherited from yesterday's GCP suspension, not a fault in my project's configuration.

What I've already tried:

1. Restart deployment — crashed within 7 seconds with the same catatonit error
2. Redeploy (fresh image pull) — same result, same error

I have NOT touched the image tag or the volume because I have no backups and don't want to risk further data loss.

Service details:

• Project: Asset Flow
• Project ID: 7c852cfe-af90-4023-87b0-b62c08b47a9c
• Environment: production (92dc88b2-017c-4e9f-bd3d-9d7153546d90)
• Postgres service ID: 5380526f-654a-408a-9f35-3773fd0aed3c
• Latest crashed Postgres deployment: a677ca4a
• Image: ghcr.io/railwayapp-templates/postgres-ssl:18
• Volume: postgres-volume (contains my only copy of production data)
• Public TCP proxy: switchyard.proxy.rlwy.net:45069 → 5432
• Downstream affected service: assetflow (assetflow.scape.com), also Crashed

Ask:

• Could the team confirm this is part of the May 19 GCP outage cascade?
• Is there a recovery path that preserves the data on postgres-volume (e.g. pg_resetwal, manual mount, or a temporary recovery container)?
• I'm happy to follow any instructions or grant access as needed — please advise on next steps.

Thanks very much.