Skip to content

How can we improve the platform?

← Atlas

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.

85 votes

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Elise shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Leho commented  ·   ·  Report

    > 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  ·   ·  Report

    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,

  • AdminTonya (Sr. Product Manager, MongoDB) commented  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    Please... just add the collection name and query. You can get fancy after that.

  • AdminAndrew Davidson (VP, Cloud Products, MongoDB) commented  ·   ·  Report

    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

Atlas: Alerts

Categories

Feedback and Knowledge Base

(thinking…)