With the Atlas API, there is functionality to add labels to various clusters like EC2. It would be great if that was exposed through the Atlas UI as well.

Session timeout value in Atlas UI defaults at 12h. Allow it to be configurable per Project or Organization, with the minimum value being 15 minutes. All Atlas users within an organization that have been idle for the duration of the configured session timeout should be automatically logged out.

Alerts can be configured to send to specific Atlas Users, but not Atlas Teams, which diminishes the value of setting up a team of users.

We need a way to easily ingest logs into Splunk. It needs to be all logs - node and web portal activity. Ideally a Splunk connector would be provided but a stop-gap measure would be the ability to configure Atlas to write all logs to an Azure storage account.

Lack of native log ingestion ability may be an Atlas deal killer for us.

Since Atlas clusters now support different sets of hostnames, it would be good to explore the feasibility of allowing users to add their own hostnames to the cluster configuration and TLS certificates such that custom connection strings can be used.

One use case for this is being able to "wrap" Atlas connection strings, such that an application's connection string would never need to change despite underlying cluster changes (cluster being moved between projects, etc.)

This could also be useful if you wished to whitelabel your cluster.

When trying to implement Atlas infrastructure for Organization/Project users, the Teams functionality is useless unless we can add pending users to a Team. Right now, if a new user doesn't login for two weeks, we can't assign them to a Team until two weeks after the implementation was supposed to be configured.

Upload good tutorials in YouTube about connecting mongodb atlas with available three options.

Please add support for the newly announced and already generally available AWS EBS feature. [1]

The top capability is: "The new gp3 volumes deliver a baseline performance of 3,000 IOPS and 125 MB/s at any volume size. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MB/s for an additional fee." [2]

That basically means decoupling storage performance from storage size.
It would eliminate all our IOPS pain as 3000k is more than enough for our usecase. Currently, we are slightly overprovisioning storage size in order to guarantee minimal IOPS performance.

[1] https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-new-amazon-ebs-general-purpose-volumes-gp3/
[2] https://aws.amazon.com/ebs/general-purpose/

Make EBS Burst Balance Metrics available within the Atlas UI. Currently it is not easy to 100% understand how much burst credits are being used and whether they have actually been depleted.

You can infer it from the IOPS metrics going above baseline IOPS and then suddenly dropping down but would be better to see the balance itself to be 100% sure. This will save support requests to do so.

Enable connectivity in Azure using private endpoints

The BSON spec includes support for UUID values, also known as GUID values.

The format of UUID values are defined in rfc4122.txt. For example,

f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Users would like to work with UUID/GUID values in Data Explorer as a fully supported data type, including search support in the RFC layout, ability to create new document fields of type UUID, support for UUID type _id fields and the ability to edit UUID values in existing documents.

The mongo shell documentation provides this example:

UUID("3b241101-e2bb-4255-8caf-4136c566a962")

The email Alerts that MongoDB provide are very useful, especially the Oplog and CPU Usage. However, the subject of the emails are not clear and does not specify the Alert type. It is just a generic "Alert". It would be great if MongoDB can add "Alert Oplog" or "Alert CPU Usage" to the email subjects to make them much more clear and helpful. Thanks!

We have a platform (as code using Terraform) where we integrate Mongo Atlas in AWS. We have multiple teams with various privileges who access the Mongo Atlas console daily basis. We would always like to manage the users in our version control. As Terraform is one of the best infrastructure configuration tools, we would like to have a terraform resource in order to manage the users via.

The speed at which usable monitoring metrics data (1m, 5m) is purged and reduced to 1hr is way too quick.

After 1hr, the ability to analyze these metrics that are crucial to investigating a performance issue were lost and hindered the root cause analysis.

I would suggest that 1m or at least 5m resolution metrics be retained for at least a week before being purged.

Achieve feature parity with AWS IAM cluster authentication support.

I'm trying to get logs from MongoDB Atlas to Splunk, and there's currently no native interface to do it, so instead of streaming to Splunk directly, I'm having to execute https calls in intervals, unzip them and then ship them to Splunk. Many products have interfaces to stream to Splunk directly, and it would certainly be handy in this situation.