Session Timeout configuration in Atlas

I’m interested in setting the “session timeout” in MongoDB Atlas for inactive sessions. How is that done?

Is there a risk to changing the “session time out” to shorter length 15 mins, there’s a warning, is that a technical reason? localLogicalSessionTimeoutMinutes It has a warning only for testing, not for production? There’s a security requirement I’ve been asked to explore to reduce the timeout to 15mins. (Default for Mongo is 30mins)

MongoDB Server Parameters — MongoDB Manual(4 kB)

Hi Norman,

What are you trying to achieve?

The localLogicalSessionTimeoutMinutes parameter needs to be set for each mongod instance in a deployment and is not a parameter currently available in the Atlas UI or API. I believe this is only suggested for testing as there will be unexpected consequences if the value isn’t set consistently in a deployment. This parameter determines when an inactive session is eligible to be cleaned up by the server so is generally a housekeeping parameter rather than a tuneable for performance or privacy.


Thanks Stennie for the reply!

I guess the mystey is solved, I was wondering where in the Atlas UI it was located :slight_smile:

I’m trying to achieve > meet a requirement our security team, as thy are asking if we can reduce the time out for inactive sessions to 15 mins, as the default is 30 mins.

So as long as the deployment is consistent across all replicas/shards for the timeout then it would be considered SAFE?

Hi @nchan,

If you want to end your sessions earlier (rather than waiting for the inactivity timeout) you can explicitly call the client end/close session method. For example in the Python driver: end_session().

I’m not sure sure if this feature can be enabled on a per-cluster basis for MongoDB Atlas (nor do I think it would improve security), however if you have a dedicated Atlas cluster you can contact the support team to discuss your requirements.

I would generally not recommending enabling features intended for test purposes in a production environment as these will not be as widely used or tested as the default values.


Thanks @Stennie for the reply, thanks for pointing that out about Atlas. Since Atlas is a managed service ,I do agree it’s best not to diverge for the “standard” setup and have any custom configurations. This feature is available onPrem, with some caveats so I’ll wait to hear back from support.

Internally for us it’s a “check box” for security reasons that we meet for a security audit, we can configure things to ensure disconnect from applications/tools. However multiple variables such as different tools, and code bases. So the initiating a disconnect from the database when there’s inactivity helps cover things missed.

thanks again for the reply!