What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

In large Atlas projects where multiple teams or microservices share a single Project ID, this creates significant "alert noise." If Team A owns 2 clusters and Team B owns 10, Team A is forced to receive notifications every time Team B’s clusters scale.

• No Granularity: We cannot use the "For Cluster" dropdown that is available for other metric alerts (like CPU or Disk usage).

• Alert Fatigue: Support and DevOps teams are being notified about events they don't own and cannot act upon.

What would you like to see happen?

Describe the desired outcome or enhancement.

Update the "Atlas Auto Scaling" alert category to support the same filtering logic used in Metric alerts. Users should be able to:

1. Select "Specific Clusters" from a dropdown when creating the alert.

2. Add a Condition (e.g., Cluster Name EQUALS X) so that notifications are only sent for relevant infrastructure.

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

This enhancement will reduce operational overhead, prevent alert fatigue, and allow teams to maintain a "Single Project" architecture without sacrificing precise monitoring.

What steps, if any, are you taking today to manage this problem?

To bridge this gap, we are currently forced to forward all project-level metrics and events to Datadog to perform the filtering there.