What is the problem that needs to be solved? Add an option (as it was in mLab) that allows to share the Cloud Provider Backup Snapshot (EBS Snapshot [1], in case of AWS) for Atlas Cluster with customer's Cloud Provider account. This action is easier, quicker and cheaper for customers than manually downloading the Atlas Snapshot.

Why is it a problem? (the pain) A) Operational pain: as of now (2020-02-18), if you require to execute disaster recovery scenario with restoration of your Atlas Cluster data outside of Atlas Clusters you'll need to create a Cloud Provider Backup Snapshot Restore job (POST /groups/[GROUP-ID]/clusters/[CLUSTER-NAME]/backup/restoreJobs/ Public API call [2]), then wait until that job will be finished and then manually download Atlas Snapshot(s) via HTTPS; B) Additional cost associated with manual restoration procedure: in order to know which Backup Snapshot file is related to which Shard/CSRS you'll need to download it, untar and check mapping.

[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html
[2] https://docs.atlas.mongodb.com/reference/api/cloud-provider-snapshot-restore-jobs-create-one/

Hi, Currently there is no option to initiate auto scaling during heavy workload/ requests comes and the cpu/ memory utilization is 75% for the even within
- 5 minutes
- 15 minutes
- 30 minutes
- 45 minutes

The system has to wait for 1 hour to autoscale to next tier.This one of the concerns for the heavy workload applications.

Idea:

Add a custom duration option as

• minutes also while monitoring the cpu / memory utilization

Example : When a CPU / Memory utilization is above 75% for the past 15 minutes , move the cluster to the next tier when auto scaling is enabled .This can also be implemented as a dropdown option ( 5min, 15 min, 30 min, 45 min, 1 hour, 3 hours , 6 hours etc)

At the moment, it appears one cannot customize the messaging or subject line of the alerts. This makes it difficult to categorize the alerts. For instance, we would like to categorize alerts into different severity levels, such that severity level will help determine the level of attention that is paid to the alerts when they trigger. If it is possible to prefix or append some customization code and message to either the subject line and/or actual message, then a monitoring team can use the custom code/message to determine the severity or category of the alert when it triggers.
Some alerts may just be informative, warnings and severe and one should be able to categorize as flexible but standardized as works for the organization.

Much like built-in roles have the ability to target all databases/any database, it would be ideal if collection actions could also target any database. Similarly to how, when adding collection actions to a custom role, if you leave the "collection" field blank, it applies to all collections in the specified DB, it would be great if you could leave the "database" field blank too (or add an "any database" option) and have the actions associated with the role be allowed on any database.

This feature gap creates unnecessary maintenance overhead for clusters with large numbers of databases. This is particularly impactful if databases are added/removed/migrated frequently, creating the need for frequent manual maintenance or some kind of API-based automation to keep the role updated so that the actions can be performed on all databases that currently exist on the cluster.

When creating an index on your UI, if the index creation gives an error, the error doesn't show on the UI, for example if you have a field of type string, and have a value longer than 1024 bytes, and try to create a normal index on this field, the UI will tell you the index it's been creating successfully, but when you go to your collection and see your indexes, this will not appear, but when you create it on the MongoDB console, it gives the following error. It would be nice to have this error shown on the UI

WiredTigerIndex::insert: key too large to index, failing 2864 { : "TXQAAE10ABdjb20uY2F1Y2hvLm5hbWluZy5RTmFtZVMACF9jb250ZXh0TXQAJ2phdmF4Lm5hbWluZy5zcGkuQ29udGludWF0aW9uRGlyQ29udGV4dFMAA2NwZU10ACNqYXZheC5uYW1pbmcuQ2Fubm..." }