## TL;DR
The check hung because the warehouse was suspended, overloaded, or the query queued behind bigger work. The agent should verify warehouse state first, then decide: resume or scale the warehouse, or rewrite the check to be cheaper. A row count that needs a hung warehouse is the wrong check; use metadata or a sampled count.

```text
agent timed out on snowflake row count check, warehouse hung, check failed
```

## Use this when
- An agent's Snowflake row count check hangs past its timeout.
- The warehouse shows suspended or overloaded.
- Validation queries queue behind production workloads.

## Not for this skill when
- The check returns a wrong count. That is a logic problem.
- The warehouse is fine but the query is slow. Tune the query.

## Steps
1. Check the warehouse state: suspended, running, overloaded. Note the state. Verify: the warehouse state is known
2. Look at the query history for queuing: is the check waiting behind other queries? Note the queue. Verify: queuing is confirmed or ruled out
3. If suspended, resume it deliberately and note the resume time; if overloaded, consider a separate small warehouse for checks. Note the decision. Verify: the capacity question is answered
4. Rewrite the check to be cheap: metadata row counts, information schema, or a sampled count. Note the cheaper check. Verify: the check stops needing a big warehouse
5. Re-run the check with a bounded wait and confirm it returns. Note the result. Verify: validation works again

## Variant phrasings
### snowflake query hung warehouse
The symptom phrasing.
### snowflake row count slow
The performance search.

Compatibility: Snowflake. Warehouse states and query history are account-level views.

## Why it happens
Snowflake separates storage from compute, so a hung query is almost never a storage problem. It is about the warehouse assigned to run it. Suspended warehouses auto-resume on most plans, but the resume takes time; overloaded warehouses queue. Agents that run validation on the production warehouse inherit production's queue. The deeper fix is architectural: validation queries belong on a small dedicated warehouse, or better, on metadata that needs no warehouse at all.

## Edge cases / pitfalls
- Auto-resume on a suspended warehouse can take minutes, longer than an agent's poll timeout. Account for resume latency.
- Row counts on huge tables are full scans. Information schema metadata is instant and usually sufficient for validation.
- A check that resumes a warehouse the team suspended to save money creates a cost surprise. Coordinate warehouse usage.
- Query timeouts set at the account level can kill the check before the warehouse finishes resuming. Check both timeouts.

## Provenance

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