-------------------------------------------------------------------Problem Statement: Inability to Scope System Alerts by Data Provider
Currently, Pulse System Alerts for build failures are binary—either enabled for everything or disabled. In complex enterprise environments, we often run hybrid deployments where ElastiCubes are powered by vastly different backend providers (e.g., legacy MSSQL/Oracle vs. modern Snowflake/Redshift/BigQuery).
When a legacy database goes down for maintenance, or when we have non-critical local CSV cubes failing, our administrators are flooded with Pulse notifications. This noise often causes us to miss critical failures in our primary Snowflake cloud data warehouse, which has direct cost and SLA implications.
Proposed Feature: Provider-Based Alert Routing
We need the ability to configure Pulse System Alert rules based on the underlying Provider or Connectivity Type of the ElastiCube.
Specifically, in the Pulse > System Alerts > Build Failed configuration, please add a condition logic or filter that allows us to include/exclude specific providers.
Configuration Example:
- Alert Rule 1: Send to CloudOps Team IF Build Fails AND Provider = Snowflake, Redshift.
- Alert Rule 2: Send to DBA Team IF Build Fails AND Provider = MSSQL, Oracle.
- Alert Rule 3: Do NOT send alert IF Provider = CSV, Excel.
Business Impact
- Noise Reduction: Eliminates "alert fatigue" by filtering out expected failures from dev/test environments or legacy systems.
- Targeted Incident Response: Ensures the right team (Cloud Ops vs. Legacy DBAs) receives the alert immediately, reducing Mean Time to Resolution (MTTR).
- Cost Management: Helps prioritize failures that impact billable cloud compute consumption.
