snowflake warehouse suspended when agent tried row count check, check failed

Not specified by the original author.

TL;DR

The warehouse was suspended to save money, so the check's query queued behind nothing: there was no compute to run it. The agent should detect the suspended state, resume the warehouse deliberately (knowing it costs money), or answer from metadata that needs no warehouse. Auto-resuming someone else's suspended warehouse is a spending decision; make it explicitly.

snowflake warehouse suspended when agent tried row count check, check failed

Use this when

• An agent's Snowflake check fails on a suspended warehouse.
• The warehouse was suspended for cost savings.
• The agent is unsure whether to resume it.

Not for this skill when

• The warehouse runs but the check is slow. That is a query problem.
• The check returns wrong results. That is a logic problem.

Steps

1. Check the warehouse state before the query: suspended, resuming, or running. Note the state. Verify: the situation is diagnosed, not guessed
2. Decide: resume deliberately for a needed check, or answer from information schema metadata. Note the decision and its cost. Verify: the spending decision is explicit
3. If resuming, allow for resume latency in the agent's wait budget. Note the adjusted budget. Verify: the wait accounts for reality
4. Prefer metadata answers for routine checks: row counts from information schema need no warehouse. Note the cheaper path. Verify: routine checks stop needing compute
5. Record the resume event with who authorized it. Note the audit trail. Verify: spending is traceable

Variant phrasings

snowflake warehouse suspended auto resume

The behavior phrasing.

snowflake check without warehouse

The cheap-alternative search.

Compatibility: Snowflake warehouses and information schema. Auto-resume behavior is per warehouse config.

Why it happens

Suspended warehouses are a cost control: no compute, no bill, but also no queries. Agents that assume a warehouse is always running hit the suspended wall and either fail the check or resume the warehouse, spending money the team chose not to spend. The information schema answers most validation questions without any warehouse at all, which dissolves the dilemma for routine checks. For the rest, resuming is fine as long as it is a decision, not a reflex.

Edge cases / pitfalls

• Auto-resume triggers on any query, including accidental ones. A misconfigured agent can resume warehouses all day.
• Resume latency varies from seconds to minutes. An agent with a short timeout fails the check even though the resume worked.
• Multi-cluster warehouses resume differently than single-cluster. Know the warehouse's shape before waiting on it.
• Some teams suspend aggressively on schedules. A check that always finds the warehouse suspended should move to metadata, not keep resuming.

Provenance

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

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

Thread query: snowflake warehouse suspended when agent tried row count check, check failed

TL;DR: The warehouse was suspended to save money, so the check's query queued behind nothing: there was no compute to run it. The agent should detect the suspended state, resume the warehouse deliberately (knowing it costs money), or answer from metadata that needs no warehouse. Auto-resuming someone else's suspended warehouse is a spending decision; make it explicitly.

Not specified by the original author.

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.

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

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

Thread query: agent timed out on snowflake row count check, warehouse hung, check failed

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.

Not specified by the original author.

TL;DR

Fix this in Snowflake by acting on the exact message first: check the exact role and warehouse grants in Snowflake, qualify the object with database and schema, and run the query as the review role itself. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

when agent tried to query Snowflake metrics it failed with connection error failure

Use this when

• The operation in Snowflake fails with this exact message: when agent tried to query Snowflake metrics it failed with connection error failure.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Snowflake, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: check the exact role and warehouse grants in Snowflake, qualify the object with database and schema, and run the query as the review role itself. Verify: confirm the query returns rows when run as the review role.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in Snowflake on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in Snowflake so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Snowflake hides objects the current role cannot see, so a missing grant and a missing object produce the same error message.

Variant phrasings

when agent tried to query Snowflake metrics it failed with connection

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: when agent tried to query Snowflake metrics it failed with connection

The how-to phrasing for the same failure in Snowflake. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Snowflake troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: Snowflake at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

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

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

Thread query: when agent tried to query Snowflake metrics it failed with connection error failure

TL;DR: Fix this in Snowflake by acting on the exact message first: check the exact role and warehouse grants in Snowflake, qualify the object with database and schema, and run the query as the review role itself. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.