## TL;DR

The warehouse killed your query for running too long. Either the model SQL is too heavy and needs slimming down, or the timeout is too tight for a legit query. Check the compiled SQL first, optimize the obvious waste, and only then raise the timeout for that model.

## Error

```text
Database Error: canceling statement due to statement timeout in dbt
```

## Steps

1. Find the killed query: open target/compiled for the model and check logs/dbt.log for how long it ran before cancellation.
   Expected: You have the exact SQL and its runtime, e.g. killed at 300s on a 6-way join.

2. Look for the usual waste: select star over wide tables, joins without filters, missing incremental filter on event_time, or a cross join from a bad join key.
   Expected: You spot at least one thing to cut, usually an unfiltered scan or a fanout join.

3. Fix the SQL: add the incremental filter, prune columns, or push the filter before the join. Re-run and time it.
   Expected: Runtime drops well under the timeout.

4. If the query is legitimately heavy, raise the timeout just for that model: on Postgres set statement_timeout in the model's config via a pre-hook or profile setting; on other warehouses use the equivalent query timeout.
   Expected: The model completes; other models keep the stricter timeout.

## When to use

- warehouse cancels a dbt query with statement timeout or query timeout
- one model consistently dies near the same elapsed time
- timeouts started after a model grew or a filter was removed

## When not to use

- dbt itself timing out waiting (that is a client-side timeout, different setting)
- the query fails fast with a syntax or permission error
- every model times out at once (that is a warehouse outage or queueing, not one query)

## Tool compatibility

- Postgres/Redshift: statement_timeout; Snowflake: STATEMENT_TIMEOUT_IN_SECONDS
- BigQuery: no statement timeout by default, check slot contention instead
- dbt pre-hooks or profile settings apply timeouts per model

## Variant phrasings

### canceling statement due to lock timeout
Different cause: waiting on a lock, not slow execution. See the deadlock skill, check for blocking sessions.

### timeout only in dbt Cloud
dbt Cloud jobs can have their own run timeouts on top of warehouse ones. Check both; the warehouse message names the warehouse setting.

## Why it happens

Warehouses cap runaway queries with a statement timeout. dbt models that scan full history, join fanout, or lost their incremental filter eventually hit it. The timeout is doing its job; the query changed, not the setting.

## Edge cases

- Raising the timeout globally hides the next slow query; scope increases to the model that needs it.
- On Redshift, check for queueing first: WLM queue wait counts toward the timeout, and the fix is queue config, not the SQL.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_07Ouldxgl8gcDL4U22Cd4w