Warehouses still on the 2-day default statement timeout
What does ZopNight detect here?
STATEMENT_TIMEOUT_IN_SECONDS defaults to 172800, a full 48 hours, so one runaway query can bill 2 days of compute before Snowflake aborts it. On an X-Small at Enterprise list rates that is roughly $72 of unplanned spend; ZopNight flags warehouses where nobody ever overrode the default.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | snowflake_wh_statement_timeout_default |
| Category | orphan |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | signals/hygiene/snowflake-wh-set-timeout.yaml |
Where it applies
Two days is the default leash
Snowflake will cancel a query that runs past STATEMENT_TIMEOUT_IN_SECONDS, but the factory setting is 172,800 seconds, which is 48 hours. A query nobody meant to run for more than a minute can therefore bill two full days of warehouse time before the platform steps in. On an X-Small at a $3 Enterprise list credit that is about $72 per runaway day; on a Large the same accident costs 8 times as much, and on a multi-cluster warehouse each affected cluster bills in parallel. The default is a leash long enough to never matter.
Exactly what trips the finding
The discoverer records each warehouse’s statement_timeout_in_seconds attribute, and
the rule fires on two values: the literal 172800, meaning the default was never
touched at the warehouse level, and empty, meaning no warehouse-level override exists.
No query history is consulted. The rule is a guardrail check, not a claim that a
runaway has already happened.
Read the parameter, and its level
SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN WAREHOUSE analytics_wh;The output’s level column is the informative part: an empty level means the value is
inherited rather than set on the warehouse, and WAREHOUSE means someone deliberately
chose a number for this workload.
One honest false-positive path
Because an empty warehouse-level value reads as “default”, an org that tightened the
timeout globally, at the account level, can still see this finding on warehouses that
inherit the tightened value. The SHOW output above resolves it in seconds: if the
effective value is sane and the level says ACCOUNT, the guardrail exists and the
finding can be dismissed. The rule reads warehouse attributes, not the resolved
parameter cascade, and says so rather than pretending otherwise.
Choosing a real ceiling
ALTER WAREHOUSE analytics_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 3600;An hour suits most ELT warehouses; interactive and BI warehouses usually deserve 300 to 900 seconds, because no human is waiting 15 minutes for a dashboard. Set the account- level parameter as the backstop and override upward on the few warehouses with legitimate long-running work, so the exception is documented in configuration instead of living in the default.