If the user has 3 peering connections in a project, it's error prone terminating one, as you may end the connection with the wrong VPC and cause a disaster. Adding a description field allows to clearly see the purpose of the peering.

We have a security reqirement that secrets must expire after 2 years.

Therefore it would be awesome if MongoDB Atlas API Keys would support an expiration date.

Somethig similar exists for the IP Whitelisting. Here we have the option to remove IP Whitelist entries after er certain time period. But for API Keys it would be better to have an expiration date and keep the API Key in the list even if its expired.

In addition it would be good to have a daily notification once the expiration date is ahead less than 30 day.

We are running into misleading error messages that learners are complaining about. This error appears when a user tries to use a $limit stage and forgets to add a $ while connected to a Free Tier Atlas cluster:
"OperationFailure: limit is not allowed in this atlas tier, full error: {'ok': 0, 'errmsg': 'limit is not allowed in this atlas tier', 'code': 8000, 'codeName': 'AtlasError'}":
This has been confusing for users. Is there a way that we can catch this issue more precisely and issue a syntax error instead?

You need to increase the notice period that you provide to your customers for changes that could affect their ability to connect to their database.

A good example of this was the upcoming change announced yesterday "Prepare for MongoDB Atlas TLS certificate root change starting May 1, 2021". You provided 3 days notice which is woefully inadequate.

I work with a lot of large financial institutions and have contractual obligations to provide them with 20 business days advance notice for any planned maintenance. This is simply not possible with the notice periods that you provide.

We need more than 100 database users, and have had the limit raised for existing projects, but new projects require us to have the limit increased. There is no way for us to verify which projects have the default 100 database users and which ones have had the limit raised. It would also be nice to track the percentage or number of database users available as a metric.

Currently Atlas IP Access List entries allow to specify only either a single source IP addresses or ranges of IP addresses using CIDR notation. It would be great if user can add a domain or url for whitelisting where the IP address or range is not static.

In your documentation and even through the atlas web api, there is no straightforward method to see what ports my clusters communicate on. This is highly frustrating as I am using the Mongodb Atlas Private endpoint and need to Allow Inbound/Outbound communications on certain ports for the endpoint to work.

Cluster names currently impose the following limits:

• Cluster names shorter than 23 characters can't end with hyphen or dash (-)




• Cluster names 23 characters or longer can't use a hyphen or dash (-) as its 23rd character.

Instead, we should either trim or replace the hyphen at the end of a 23 character name.

page security/network/accessList

the list of IP addresses is unsorted and unmanageable

please allow sort by IP or Name (Comment)

It shows "SAML Error" and redirects the login page to cloud manager. As a result the login success is never passed to feedback.mongodb.com, it's necessary to login again (on the second attempt, it works)

The easy migration system seems to check the total disk space used on the source machine, and does not discriminate between that disk space used for MongoDB (which will be needed on Atlas) and those used for other applications.

Because the source system contains a lot of logs and a complete copy of our databases in different folders, we have had to configure Atlas to use >2x the actual disk space it'll need.

Allow manual addition of externally-hosted non-voting (hidden) node(s) to an Atlas cluster. This would permit:
- compliance with data management rules that require a copy of all data to be kept in-house (ie outside cloud)
- easier migration out of Atlas for real-time DB use cases where a stop/backup/restore is not a feasible route

It is possible to link multiple orgs to each other. It should therefore be possible to use a single API key to access all linked orgs.

Show what parts of the document are failing against a defined validation schema

Could we please consider boosting MongoDB's geospatial capabilities by incorporating Turf.js into Atlas. I would hope this would be an integration similar to Lucene in that it exposes some functionality through the UI, and some through aggregation. It would allow us to gain a huge amount of functionality. https://turfjs.org/

In the Atlas UI, allow to add a description in the IP's allowed to use an API key. This may improve security and ease management as it allows to easily maintain this list up to date.

Please enable security key (e.g. https://www.yubico.com/gb/product/yubikey-5c-nfc/) option for MFA. Ideally using FIDO2 protocol

Please allow tagging at a cluster level. This will help in storing related metadata if required.