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

***

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

<figure><img src="https://3620459840-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnSbIoBjUxWTGNWa9gGw7%2Fuploads%2Fgit-blob-ca2c9587d9d7b1e0b8856e357f9a205e244ee933%2Fsavings-by-target-frequency.png?alt=media" alt="Estimated savings by target frequency"><figcaption><p>Estimated savings by target frequency</p></figcaption></figure>

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 %}