It would be nice to get quick access to the name of the replica set from the cluster overview page.

In Atlas, it would be ideal if you could specify a percentage of total memory as the threshold for the "System Memory: Available Is..." rather than a literal number value. If it was possible to set this as a percentage, then the alert could be applied to all hosts in a project, rather than having to set hostname conditions and create a separate alert for each cluster.

since as documented there are limitation on network traffic in M0/M2/M5 instances, it is mandatory to have a metrics/alerts (also for free ones) to monitor this value in a 7d sliding window

The "Host has index suggestions" alert notification does not contain any reference to the host/deployment that triggered it making it hard to figure out where it came from. A hostname reference would be very helpful.

We would like to consume your status RSS feed to help us programmatically warn our internal groups when you have issues in a given region. One problem that we see with this is that the messages that we have seen posted are pretty inconsistent with how they specify regions. Examples: Oregon (us-west-2), AWS EU-WEST-2, AWS Sao Paulo. It would be very helpful to us, and probably your other customers as well, if the messages were more consistent in how they reference AWS regions.

It would be helpful to be able to search for a trigger condition in the Alert builder when creating/editing an alert.

Currently, you need to scroll to find specific conditions, but the list is long so it can take some time to find the particular one needed.

Add process measurements for monitoring WiredTiger data handles.

From Atlas documentation https://docs.atlas.mongodb.com/reference/atlas-limits/#collection-and-index-limits :
> While there is no hard limit on the number of collections in a single cluster, the performance of a cluster might degrade if it serves a large number of collections and indexes. Larger collections have a greater impact on performance.

but now there is no way to get this information except db.serverStatus()

Atlas exposes a few hardware metrics including Util% (presumably obtained from iostat or similar). However this metric is not very significant in the age of SSDs - a volume could be 100% utilized and still have spare capacity. A more useful storage-level metric is Average queue length - this is easier to interpret (high queue length = storage contention).

Would it be possible to add this metric to Atlas monitoring?

When a shared cluster has reached it's limit and the cluster is throttled, an email should be sent to each db-owner affected. This would save your customers AND your support a lot of time troubleshooting.

Right now there is no way for a db-owner to see this information, let alone get that information, except for asking support for help.

Within Atlas today, we have a number of channel options to send alerts (Ex. OpsGenie, Slack, VictorOps).

I would like to see a hook integration provided by Atlas so any tool can recieve alerts from their cluster. Ex. I can recieve my cluster alert in Microsoft Teams.

3rd party hooks can increase the stickiness of Atlas and improve freedoms for teams and their existing toolsets.

Timestamps in Metrics plots are displayed in 24-hour time format, but the date/time filter inputs require 12-hour time (using am/pm).

screenshot: https://p-37FYgJ.b1.n0.cdn.getcloudapp.com/items/L1upe7Wv/Image%202020-06-25%20at%204.28.22%20PM.png?v=ec3b0551ea4035a207a90ab83817bba6

12-hour time is not widely used around the world, and it is cumbersome to use in the date pickers especially give that other parts of the UI use 24-hour time.

Can we update these date pickers to use 24-hour time instead?

Our main concern is 'Host experienced a rollback' is not an alert option!

Ideally, anything that shows up in the activity feed should be available as an alert.

This is a request to separate Atlas metric graphs of the outgoing traffic from the internal/replication traffic in Atlas cluster

Have an integration with AWS Cloudwatch to send the metrics from MongoDB Clusters to Cloudwatch so metrics and alarms can be setup in CW.

It would be useful, and contribute to a complete alert experience, to have auto-scaling event alerts configurable in project alerts. Users should be able to send alerts to their target system of choice, and prevent numerous alerts to specific users.

Currently auto-scaling alerts are only emails to project members (as per the following https://docs.atlas.mongodb.com/cluster-autoscaling/#acknowledge-auto-scaling-events).

Examples of configurable alerts:
- Scale-up unsuccessful due to max cluster-tier too low -> change email recipient of these alerts
- Scale-up event has occurred -> send alert via SMS and Slack.

Implement better monitoring and alerting for WT dirty cache ratio. This should include sub-minute resolution and support an understanding of eviction workload as well as performance impact of checkpoints under heavy write workloads.