Allow configurable execution timeout for Alerts (enable runs >10 minutes)

What is the problem or goal the end user is trying to solve or accomplish?

Some alert SQL queries (e.g., complex aggregations on large partitions, heavy window functions, or cross-warehouse joins) legitimately take longer than 10 minutes. Today, Alerts appear to be capped by a backend/system timeout (~10 minutes), causing runs to fail even when the database would eventually return. Users need Alerts to complete successfully for long-running but valid checks.

How are they solving it currently?

Attempting to optimize/denormalize or pre-aggregate upstream (materialized tables, incremental models), which isn’t always feasible.

Lowering data volume or time windows, which weakens alert fidelity.

Converting to a Report (which has a configurable “Working timeout”) and then manually checking results, which loses alert semantics/notifications.

Externalizing the alert logic to other schedulers/monitors (dbt, Airflow, custom scripts) and posting to Slack/Email outside Preset.

What is the recommended solution by the Customer?

• Add a per-Alert “Working timeout” (or “Max execution time”) setting - similar to Reports - configurable via UI and API, with a higher allowed ceiling (e.g., up to 60 minutes). The run should respect the smallest of: this Alert timeout, any DB/driver statement timeout, and any global worker limits. Include guardrails:

• UI validation/warning if the timeout exceeds the Alert schedule interval.

• Clear run metadata showing wall-clock time, DB time, and which limiter ended the run (DB vs. Alert timeout vs. global).

• Workspace-level default & max caps controllable by admins.