MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Add new feedback Subscribe
Status Submitted
Categories Atlas
Created by Guest
Created on Nov 19, 2019

RELATED FEEDBACK

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.
  • Attach files
  • Guest
    May 12, 2025
    > 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".
    Reply
  • Guest
    Aug 28, 2023
    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,
    Reply
  • Guest
    May 17, 2022
    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?
    Reply
  • Guest
    Mar 3, 2022
    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.
    Reply
  • Guest
    Feb 22, 2021
    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.
    Reply
  • Guest
    Feb 22, 2021
    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.
    Reply
  • Guest
    Jun 27, 2020
    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.
    Reply
  • Guest
    Jun 10, 2020
    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.
    Reply
  • Guest
    May 28, 2020
    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.
    Reply
  • Guest
    May 21, 2020
    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.
    Reply
  • Guest
    May 15, 2020
    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
    Reply
  • Guest
    May 14, 2020
    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.
    Reply
  • Guest
    Mar 2, 2020
    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.
    Reply
  • Guest
    Feb 19, 2020
    Please... just add the collection name and query. You can get fancy after that.
    Reply
  • Guest
    Nov 22, 2019
    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
    Reply