Suggested actions for alerts
Alerts are often very cryptic & don't provide any useful information. For example, when alerting that queries are returning too many rows, without informing me the query or at least the collection, that's very useless. I'm looking at a replication oplog window alert right now and I have no idea what to do about it.

-
Leho commented
> We are exploring ways to improve alerts.
> Can you be more specific - what alerts are you receiving that are cryptic and what information would you like added to that specific alert to make it more actionable?Nothing seems to have improved by mid-2025.
Does everyone have some super-convenient workaround, so Atlas Alerts simply don't matter at all? What is it?
For quoted question: see attachment screenshot. This alert display couldn't be more vague.
* Which host? Link?
* Which cluster? Link?
* What is the index suggestion? Link?
* What triggered the index suggestion? Link?
* Links to specific screens to dig into details.Current UX seems what I believe could be called a "dumpster fire".
-
Konstantin commented
I agree. It's really bad if you get an alert and have to start digging and learn tooling to find out which query the alert was probably about,
-
We are exploring ways to improve alerts. Can you be more specific - what alerts are you receiving that are cryptic and what information would you like added to that specific alert to make it more actionable?
-
Alexander commented
Actually the DB and the collection(s) would be a good start, but right now there is no chance to identify these queries but to log all queries to the profiler.
Especially on dev systems where the queries may not be slow (so profiler mode 1 with eg 50ms does not hit), but still not performant, the DB, collection and shape would be very good to get. This way queries can be optimized before getting into prod. -
Locus commented
If the system knows all the queries which were running at the time the alert was generated, it only makes sense to send the query shape with the Alert - OR - if that information is not immediately available, it still makes sense to send one email per query shape with an issue so that the customer can look into each query shape separately and mitigate.
-
Chandler commented
It would be ideal if the alert notifications for Query Targeting ratio alerts included a reference to the query shape that caused the alert to fire. This would assist customers in locating the exact query/queries with poor targeting ratios so that they can be optimized in a more expeditious manner.
-
Rahul commented
The information in notifications is very less and almost impossible to get an idea about what is going wrong. So, please give us basic solution to this problem.
-
Nishad commented
Basic info like which query returned over 1000 objects or at least clicking the link takes us to that query would be nice at this time.
-
Tyler commented
Yeah today I get e-mails that say the ratio is off but i cannot tell what query performed the triggering action without spelunking the logs... would be much nicer if it was included in the alert.
-
Sergey commented
If you want to catch full scan on collection you could set up alert "Query Targeting: Scanned / Returned > 1".
OPS Manager does not provide any details where it was triggered.
it would be nice to get db/collection/query which caused this issue. Query still can be fast (for example, not many document in collection yet or hardware is idle/fast at the moment) and will not go to slow operation group. -
AdminRez (Admin, MongoDB) commented
Hi Timo -
Completely hear you. This has been an often requested feature from our customers. We are working on it and hope to have a solution this year. I will inform this thread as soon as we are close to being done.
Feel free to email me at rez@mongodb.com if you wish to discuss further.
Rez
-
Timo commented
Yup, currently receiving hundreds of alerts a day for "Query Targeting: Scanned Objects / Returned has gone above 1000..." but profiler is catching nothing as the queries are still executed fast enough in terms of milliseconds.
I absolutely agree with Eric, just point at the collection/query in question, no need to get fancy with index recommendations or such.
-
Diego Rodriguez commented
For alerts of type "Query Targeting: Scanned Objects / Returned has gone above 1000...", being able to track the query that triggered the alert or maybe contributed more to it would be of big help.
-
Eric commented
Please... just add the collection name and query. You can get fancy after that.
-
Hi Omar, Thanks for flagging this.
We completely agree and want to generally make alerts more prescriptive where possible. There are many classes of alerts so we're starting where we can make the biggest difference. For example for the alert you referenced, we'd like to move to a model in the future where we alert when we can see a way to improve e.g. when we have an index suggestion.
-Andrew