We are experiencing critical instability on our MongoDB service in production.
The database becomes completely unreachable every 1–2 minutes, and no client can connect during these periods.

Connectivity impact:

• Application cannot connect

• mongosh cannot connect (internal or public URL)

• mongodump cannot run

• TCP connections are reset (ECONNRESET)

At the moment, there is no reliable way to access the database from anywhere.

Key observations

• Inside the MongoDB container, the mounted volume (/data/db) is reported as 100% full:

  df -h /data/db
  /dev/zd22208  4.4G  4.4G  0  100% /data/db
  

• In contrast, the Railway UI reports the same volume (industrious-volume) as using only ~300–500 MB.

• MongoDB repeatedly crashes or restarts, but crash logs are not visible:

  • No relevant crash logs appear in Railway logs

  • No clear shutdown or panic messages are exposed

• This makes it difficult to diagnose the exact failure point while the service continues to flap.

This suggests a filesystem-level disk exhaustion not properly reflected in Railway’s volume metrics, potentially combined with missing or inaccessible runtime logs.

Impact

• Production database completely inaccessible

• Application downtime

• No backups possible

• No visibility into crash root cause (logs missing)

• Risk of data corruption if instability continues

Environment

• Service: MongoDB

• Environment: Production

• Volume: industrious-volume

• MongoDB version: 7.0.x

• Region: europe-west4

Request

We need urgent help to:

1. Restore stable access to the MongoDB database

2. Understand why the volume appears full inside the container but not in Railway metrics

3. Investigate why MongoDB crash/restart logs are not visible

4. Ensure the database can be stabilized without data loss

This issue is production-blocking and critical.