# snowflake_wh_statement_timeout_default

> 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.

Source: https://zop.dev/integrations/snowflake/recommendations/snowflake-wh-statement-timeout-default
Updated: 2026-08-19

---

## 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

```sql
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

```sql
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.