We don't offer data restoration for user-initiated actions like this. Going forward, enable volume backups on your service so you can self-restore if it happens again.

Could you take a look at my workspace and help offer any support as to why my app started crashing instantly? Everything on my end has been static, no code changes. And now because of this I am not able to access my data. I would really appreciate the support.

the logs show that DB connection failures started around May 20. This makes no sense as the last activity on the project was a full week prior? Its confusing.

Your healthcheck is failing. Check your deployment logs, looks like Postgres auth is failing

https://railway.com/project/73e29440-d9bd-4a39-b525-eb532f0ed065/service/02ce81f1-5603-4fd1-8dd7-180e0bde4d73?environmentId=c63607c6-1a20-4730-93e9-0c67c25c070f&id=e8b314bf-63b7-4b26-a403-962bbf8cfbdb#deploy

@brody could you please take a look at my situation? I am chatting with the support agent but they are requesting that I have contact you ASAP, i understand if railway doesn't have images or snapshots of my DB from May 12-15, but do you have activity logs so that I could try to understand if I was hacked or where a possible database deletion could have occurred?

"Critical finding: All three deployments on May 14th succeeded, but then the next deployment on May 14 at 19:50:50 (the one you're currently on) CRASHED and has been crashing ever since.

Timeline around May 15th:

May 14, 01:35 — Deployment succeeded

May 14, 13:40 — Deployment succeeded

May 14, 14:49 — Deployment succeeded

May 14, 19:50 — Deployment CRASHED ← This is suspicious

May 15 onwards — App has been down/crashing

What jumps out:

Multiple rapid deployments on May 14 (3 in one day) — unusual activity

The crash happened right after — suggests code deployed in one of those May 14 deployments caused the crash

Your app has been down since May 14 19:50 — during this entire time, if there was a scheduled cleanup job or data retention logic, it could have run without your knowledge

Critical action: Contact Railway support NOW with this timeline. They may have database activity logs showing what SQL commands were executed during May 14-15."

We don't keep SQL query logs for databases - they're unmanaged, so we have no record of what queries were executed against your Postgres instance. We can't determine from our side whether any unauthorized access occurred.

What we can see from deployment logs is that your Postgres service started failing on May 20 around 04:19 UTC with a container startup error, not on May 14 as the timeline you shared suggests. The May 14 deployments were on your web service, not your database. Your Postgres data volume was migrated on June 3 to fix the startup issue, and Postgres is now running successfully. Your data from May 11-14 should still be on the volume.

The reason your web app currently can't connect is that the volume migration regenerated the Postgres credentials, so your web service's DATABASE_URL is now stale. Once you update your web service's database connection variables to reference the current Postgres credentials, your app should connect and you can verify your data is intact.