What Is Snowflake Query Timeout?
Snowflake query timeout controls how long a query can run or queued before it is automatically canceled. Some queries can run for very long periods, either because of inefficient query design or because of query complexity and dataset size.
Snowflake charges users according to database runtime, so long running queries can dramatically increase Snowflake costs. The default query timeout in Snowflake is 2 days (172,800 seconds). For large datasets, this means that long-running queries could cost hundreds or thousands of Dollars.
Snowflake query timeout is customizable, and most users should set a shorter timeout than the default to avoid unexpected costs and other negative consequences.
Technically, when a timeout occurs, Snowflake terminates the query, and the user receives an error indicating the operation exceeded the specified time limit.
This is part of a series of articles about snowflake query optimization
The Importance of Setting Query Timeouts
Setting query timeouts is crucial for several reasons:
- Controlling costs: Since Snowflake charges for compute usage based on query execution time, queries that run for days can lead to unexpected expenses. Defining a reasonable timeout threshold helps avoid unnecessary resource consumption and optimize costs.
- Resource allocation: In multi-tenant environments, where multiple users and applications share resources, long-running queries can monopolize compute power, slowing down other operations. By defining a timeout, users prevent any single query from using too much of the system’s resources.
- Data inconsistencies: When queries run for extended periods, especially under conditions like network failures or hardware issues, the results could become outdated or unreliable.
Understanding Snowflake’s STATEMENT_TIMEOUT and TASK_TIMOUT Commands
Snowflake has three main commands that allow users to customize query timeouts.
STATEMENT_TIMEOUT_IN_SECONDS
STATEMENT_TIMEOUT_IN_SECONDS ensures query execution time is constrained to a predefined limit. When a query exceeds the specified time, Snowflake automatically terminates it, returning an error message indicating that the query exceeded the allowed time.
By setting this timeout, administrators can prevent queries from running indefinitely, which can otherwise lead to excessive consumption of compute resources and, ultimately, inflated costs. Setting an appropriate value for STATEMENT_TIMEOUT_IN_SECONDS requires an understanding of the typical query runtime for workloads.
STATEMENT_QUEUED_TIMEOUT_IN_SECONDS
STATEMENT_QUEUED_TIMEOUT_IN_SECONDS controls how long a query can remain in the system’s execution queue before being canceled. When resources are heavily used or unavailable due to other queries running, Snowflake may queue a new query until the necessary resources become available. This queueing is a normal part of resource management, but it can lead to delays, especially if the system is under high load.
The STATEMENT_QUEUED_TIMEOUT_IN_SECONDS parameter allows administrators to prevent a query from waiting too long before being executed. If the queued time exceeds the specified limit, Snowflake terminates the query with an error, freeing up resources for other tasks. This is particularly useful when managing workloads with varying levels of urgency.
For example, time-sensitive queries like reporting or real-time analytics may need to be executed as soon as possible, and setting a shorter queued timeout ensures they don’t get stuck waiting for resources. Less critical queries could be given a longer queued timeout without disrupting overall performance.
USER_TASK_TIMEOUT_MS
USER_TASK_TIMEOUT_MS defines the maximum duration that a user-defined task can execute before it is terminated. These tasks, such as scheduled jobs or automated processes, are typically independent of interactive user queries but still help manage data workflows in Snowflake. By setting this timeout, administrators can ensure that tasks that are running too long are automatically stopped.
This parameter is particularly useful for background operations that may be prone to unexpected delays due to data size, network issues, or task misconfigurations. For example, if a scheduled data transformation job or ETL process takes longer than expected, a timeout can prevent it from running indefinitely and consuming compute resources unnecessarily.
How to Configure Query Timeouts in Snowflake
Configuring query timeouts in Snowflake can be done in several ways, depending on whether admins want to set them for an account, user, session, or warehouse. All of these configurations utilize the STATEMENT_TIMEOUT_IN_SECONDS parameter, allowing administrators to have granular control over how long queries can run before they are terminated.
Session Query Timeout
To check the current query timeout setting for the active session, use the following command:
show parameters for session;
To set a query timeout of 30 minutes (1800 seconds) for the current session, run:
alter session set statement_timeout_in_seconds = 1800;
User Query Timeout
To view the query timeout setting for a specific user, such as analytics_user, execute:
show parameters for user analytics_user;
To set the query timeout to 30 minutes (1800 seconds) for the user, run:
alter user analytics_user set statement_timeout_in_seconds = 1800;
Account-Wide Timeout
To check the current query timeout setting for the entire Snowflake account, use:
show parameters for account;
Typically, the default timeout is 2 days (172,800 seconds). To set it to 1 day (86400 seconds), use the following command:
alter account set statement_timeout_in_seconds = 86400;
Warehouse Query Timeout
To check the query timeout setting for a specific warehouse, such as COMPUTE, execute:
show parameters for warehouse compute;
To modify the query timeout to 30 minutes (1800 seconds) for the warehouse, run:
alter warehouse compute set statement_timeout_in_seconds = 1800;
Users can also set the query timeout when creating a new warehouse:
create warehouse compute
warehouse_size = ‘XSMALL’
statement_timeout_in_seconds = 1800;
Which Query Timeout Is Used?
When multiple query timeout settings are configured, Snowflake enforces the lowest timeout value. For example, if a session has a timeout of 1 hour and a warehouse has a timeout of 10 minutes, any query that runs for longer than 10 minutes will be terminated by the warehouse setting. This ensures that the most restrictive timeout takes precedence, preventing excessive resource usage.
Task Timeout Configuration
Task timeouts in Snowflake are managed using the USER_TASK_TIMEOUT_MS parameter, which is expressed in milliseconds. The default timeout is 1 hour. To check the current timeout for a task, such as example_task, use:
show parameters for task example_task;
To set the timeout to 30 seconds (30,000 milliseconds), execute:
alter task example_task set user_task_timeout_ms = 30000;
Billing Considerations for Cancelled Queries and Tasks
When a query or task is cancelled due to a timeout, the resources consumed up until the cancellation still count towards the total compute usage. This means that even if a query is terminated early, it will still incur charges for the time it ran, including any resources consumed while waiting in the execution queue.
For queries, this includes the CPU time spent on the actual query execution and any associated disk I/O operations. Similarly, for tasks, charges will apply based on the duration the task was running before being terminated. It’s essential for administrators to account for these potential costs when setting query and task timeouts.
To minimize unexpected expenses, configure timeouts based on typical workloads and expected query durations. Setting timeouts too low can result in frequent cancellations, leading to increased compute costs due to partial execution, while timeouts that are too high might allow inefficient queries to run longer than necessary, further escalating costs.
Additionally, Snowflake provides the ability to monitor query and task usage with tools like the QUERY_HISTORY and TASK_HISTORY views, allowing users to analyze execution times and resource usage. This can help administrators fine-tune timeout settings and optimize cost management strategies.
Best Practices for Optimizing Timeout Configuration
Here are some of the ways that development teams can ensure the optimal configuration for query timeouts in Snowflake.
1. Right-Size Warehouses and Suspend Intelligently
Assigning an appropriately sized warehouse can reduce query execution and queuing time, lessening the likelihood of hitting a timeout. Regularly revisiting warehouse size and scaling policies is necessary, especially when data volumes or workload complexity increase. Snowflake’s auto-suspend feature can help minimize waste when warehouses become idle after query cancellations.
By configuring intelligent suspend thresholds, organizations reduce costs associated with unused compute while ensuring capacity is available as soon as workloads resume. Monitoring warehouse utilization and aligning suspend settings with query patterns delivers both performance and cost benefits.
2. Balance Query Complexity with Adequate Timeouts
Query timeout effectiveness depends on realistic alignment with query complexity and expected runtime. Simple queries may complete in seconds, while complex, multi-join analytics can require several minutes to hours. Setting blanket timeouts too low can disrupt legitimate business queries, whereas excessively long values undermine the protective benefit of timeouts.
Collaboration between data engineers, analysts, and administrators is necessary to assess typical runtimes and adjust timeouts according to business priorities. Establishing performance baselines and periodically reviewing them helps identify queries requiring optimization rather than simply increasing timeout windows.
3. Use Resource Monitors to Track Usage
Resource monitors in Snowflake build on timeout parameters by offering more advanced controls for tracking and managing credit usage. Setting up resource monitors allows administrators to enforce thresholds, send alerts, or even automatically suspend warehouses when credit usage exceeds defined limits. This adds another layer of cost control beyond individual query and task level timeouts.
Regularly reviewing resource monitor activity helps surface patterns of inefficiency or misuse, providing actionable data to tune both query optimization and policy enforcement. Integrating usage tracking with timeout events helps teams understand where operational issues originate and take corrective actions before costs spiral out of control.
4. Continuously Review and Revise Timeout Policies
Data warehouse usage patterns change over time as new workloads are introduced or business priorities shift. Timeout policies set during implementation may become ill-suited for evolving requirements. Without regular review, organizations risk either excessive costs from relaxed policies or user frustration from policies that are too strict.
Effective time out strategies depend on ongoing collaboration between IT, engineering, and business users. Scheduling periodic reviews of timeout settings, backed by performance and cost metrics, ensures alignment with current workloads and future growth. Soliciting feedback from stakeholders and updating policies as required fosters a culture of system optimization.
Optimizing Snowflake Query Cost with Seemore Data
Snowflake’s native timeout settings are essential for controlling query execution times, but they don’t offer full visibility into why certain queries or tasks drive costs. Seemore Data addresses this by surfacing cost drivers in real time and enabling teams to trace spend to specific users, jobs, or processes. With continuous monitoring across the full data stack—from source to warehouse to BI—teams can quickly identify inefficiencies, enforce budget boundaries, and make informed adjustments before costs spiral out of control.
Seemore also helps teams forecast usage more accurately and plan future budgets with real consumption data. Data engineers can define smart budgets by warehouse, domain, or project and set up proactive alerts to prevent overruns. When paired with Snowflake’s timeout configurations, this visibility allows organizations to align their data usage with business goals, track burn rate against real-time KPIs, and attribute costs precisely to the activities that generate them. This makes timeout management part of a broader, data-driven cost optimization strategy.
