# Compute Idle Optimization
## Overview
Compute Idle Optimization identifies query patterns that run so frequently that the warehouse never auto-suspends, even though each individual execution is sub-second.\
The warehouse stays alive between executions, accumulating idle compute costs that can dwarf the actual query cost.
{% hint style="info" %}
**Required role to configure usage exclusions:** [Editor](/external-docs/fundamentals/settings/user-roles.md) or higher.
Users with lower roles can view insights and mark them as Done, but cannot change account-wide usage exclusions.
{% endhint %}
***
## How It Works
### Detection Logic
Seemore analyzes query history and warehouse uptime to find high-frequency query patterns that prevent auto-suspend. A pattern is flagged when it meets **any** of the following three criteria:
#### 1. High Execution-Time Coverage
A single query pattern consumes a large share of the warehouse's total uptime. This indicates the query itself is actively using compute resources for a significant portion of every run window.
#### 2. Keep-Alive Pattern
A single repeating query is the **only workload** running during most warehouse run windows. Each execution may take only milliseconds, but because the query fires again before the auto-suspend timeout, the warehouse never shuts down.
**Example:** A monitoring query runs every 52 seconds. Each execution takes \~66 ms, but the warehouse resumes 561 times per day and sits idle 98% of the time — costing thousands of dollars per year in wasted compute.
#### 3. Single-Orchestrator Pattern
All queries in most warehouse run windows originate from a **single user or service account**. Even though the individual queries differ, they collectively keep the warehouse alive. This catches orchestrators (e.g., a staging service account) that fire many distinct queries at short intervals.
***
### Idle Time Analysis
For each flagged warehouse, Seemore surfaces key utilization metrics:
* **Idle percentage** — fraction of total uptime spent waiting for auto-suspend.
* **Resume events per day** — how often the warehouse wakes up.
* **Average run duration** — how long each resume-to-suspend cycle lasts.
* **Average query duration per run** — how much of each cycle is productive work.
These metrics help you understand how much of the warehouse's cost is productive versus wasted.
***
### Cost Estimation
Each insight includes a **savings breakdown** showing estimated annual savings at several target intervals. This lets you compare the trade-off between different frequency reductions.
Estimated savings by target frequency
For each high-frequency query, Seemore also calculates a **recommended interval** — the smallest standard interval that is at least double the current frequency but no more than five times higher. This ensures a meaningful cost reduction without an overly drastic schedule change.
***
## Remediation
1. **Reduce query frequency** — adjust the pipeline schedule, cron job, or orchestrator that fires the high-frequency query to match the recommended interval.
2. Mark the insight as **Done** in Seemore once the change is applied.
***
## Configuration
| Parameter | Default | Description |
| --------------- | ------- | --------------------------------------------------------- |
| Analysis window | 21 days | How far back Seemore analyzes query and warehouse uptime. |
{% hint style="info" %}
If you have configured **Exclude Users from Usage**, excluded users' queries are still considered for this insight. Compute Idle Optimization evaluates warehouse-level uptime patterns, so all query activity — including service accounts — is relevant to determining whether a warehouse is being kept alive unnecessarily.
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.seemoredata.io/external-docs/fundamentals/our-features/waste-reduction/compute-idle-optimization.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.