Does a re-deploy of your database help?

No. I've tried to re-deploy twice and, as i said, they are being reported as manually canceled.

SNAPSHOT_CODE completes instantly ✓

CREATE_CONTAINER enters pending state and never completes

No build logs, no deploy logs, no error recorded

No failure stage or failure reason recorded

This pattern repeats across multiple redeploy attempts

What I've already tried:

Redeployed the service twice

Waited 12+ minutes for container creation to complete

Verified service configuration is valid (volume mount, TCP proxy, env vars all correct)

Confirmed the image (mysql:9.4) resolves successfully

Why this isn't a config issue:

The last successful deployment (April 27) used identical configuration

SNAPSHOT_CODE completing proves the image pulls successfully

No configuration errors are reported

Current status: The deployment is stuck indefinitely in CREATE_CONTAINER. Redeploying again will likely result in the same hang.

Request: Please investigate why CREATE_CONTAINER is hanging on this MySQL service. This appears to be a platform-side infrastructure issue, not a user configuration problem.

Thank you.

I appreciate opening the thread to the community, but I believe this issue requires investigation by the Railway infrastructure team rather than community troubleshooting.

Here's why:

• The MySQL service had been running normally for months without configuration changes.
• The persistent volume is still attached and contains approximately 315 MB of data.
• The application deployment is healthy (Vercel deployment succeeds), but the application cannot connect because the database is unavailable.
• The Railway Database UI cannot connect to the service.
• External clients (DBeaver) also cannot establish a connection.
• The service console reports "container stopping" / "connection lost", while the deployment appears as Active.
• There are no MySQL startup logs available to diagnose the issue from the user side.

At this point I don't have any additional actions available. The database is inaccessible through every available interface.

Could someone from the Railway team please verify the health of this service internally, including:

• the container lifecycle;
• the persistent volume attachment;
• the internal MySQL process status;
• and any infrastructure events affecting the us-west2 region?

This database is the production environment for our application, so any assistance would be greatly appreciated.

Thank you.

Hi @ray-chen,

Just following up on my reply from yesterday. I'm not sure if you had a chance to read it yet.

Unfortunately, the issue is still ongoing and the database remains completely inaccessible. I have already tried multiple re-deploys, but they did not resolve the problem.

This is our production database, and our team is currently unable to use the application because of this incident.

Could you please let me know if someone from the Railway team is investigating this internally, or if there is any update you can share?

I would really appreciate any assistance, as this has become quite urgent for our operation.

Thank you.

Create a new instance of mysql and see if Railway allows you to attach the existing volume , not sure if this help if not Migration will be the only thing you can do check with railway support if they can help for backup the data