Hey trai,

Here's how Serverless works: https://docs.railway.com/reference/app-sleeping

I suspect that WiredTiger (the checkpoint / WAL mechanism) is emitting logs every 60 seconds and that might be keeping the service alive.

Thank you for the response.

I have done some more digging and found that the issue could be related to the Next.js server sitting next to it. You can view its Network usage graph in the image, there is a constant 8KB to 4KB inbound and outbound traffic that prevents it from sleep. The Next.js server is also configured with "Serverless" enabled.

I suspect that this Next.js server which is connected to the MongoDB instance is what leads to the MongoDB service not being able to sleep.

The network pattern is interesting and looks like it could be related to some Health checks or collecting metrics for the dashboard.

Do you have any idea what could lead to this?

If you use the NPM mongodb driver to connect then it might be the culprit. I had a similar issue with a SvelteKit and MongoDB combo. I had a singleton connection pool and this would trigger a heartbeat ping from the driver to MongoDB via the private network. And since MongoDB responds, both services never went to sleep. The solution was creating a connection pool per request and closing it before returning a response.

maiertech is right -- any sort of network activity directly to the container will keep it alive. Mongo is pretty bad about this but it's also true of Postgres (you'll want pgbouncer for that)

You are right. Thank you for the support echohack and maiertech.