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.

When configuring Atlas alerts to be sent via Slack, there are cases where different alert types need to be routed to different Slack channels (e.g., critical alerts to #db-critical, warning alerts to #db-warning). However, the current UI only allows specifying a single Slack channel per integration. When attempting to configure a second channel, an error message appears: "Error sending test message. Check your credentials and try again." Interestingly, if you ignore this error and proceed, the configuration actually works and alerts are delivered to the intended channels successfully. This indicates that the backend technically supports multiple channel configurations, but the UI validation incorrectly flags it as an error.

What would you like to see happen?

Describe the desired outcome or enhancement.

1. Officially support configuring multiple Slack channels per Slack integration for different alert types.

2. Remove or fix the misleading error message that appears when adding a second Slack channel, since it works correctly despite the error.

3. Ideally, provide a per-alert-type channel mapping UI so users can intuitively assign specific Slack channels to specific alert categories.

Why is this important to you or your team?

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

As a Database Reliability Engineering team, we need to route alerts by severity and type to different channels so the right team members are notified promptly. Currently, the false error message causes confusion and hesitation — team members are unsure whether the configuration is actually valid. This undermines confidence in the alerting system and creates unnecessary friction during setup. Proper multi-channel support would improve our incident response workflow and reduce alert fatigue by ensuring each channel only receives relevant notifications.

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

We currently ignore the error message and proceed with the configuration, which technically works. However, this is not ideal because new team members or auditors may question the validity of a setup that was configured through an apparent error state. We have documented this workaround internally, but it feels like a hack rather than a supported workflow.