Introduction

Snowflake incidents often present at one layer and originate at another. A dashboard timeout could be DNS, authentication, warehouse queueing, blocking, or inefficient scanning. A file in cloud storage might not load because an event never reached Snowpipe, the stage path differs, or conversion failed. A disciplined workflow identifies the earliest broken dependency before changing configuration.

Troubleshooting Methodology

Use five questions for every incident:

  1. What exact operation, object, account, and timestamp failed?
  2. What stable evidence exists, such as query ID, filename, request ID, task name, or pipe name?
  3. Which control owns the observed behavior?
  4. Which prerequisite must succeed before that control can act?
  5. What observable result will prove recovery?

Capture evidence before restarting, resizing, regranting, or recreating objects. Broad changes can erase the original signal or introduce a security or cost problem.

Common Issues

Data loading failure

Begin at the file boundary. Confirm the expected filename, stage, path, storage integration, and visibility. Then inspect copy output, validation results, load history, or pipe status.

Possible causes include:

  • The pattern or prefix does not select the file.
  • The file was already recorded as loaded.
  • The file format parses fields incorrectly.
  • A value cannot convert to the target type.
  • The role lacks stage, table, pipe, or warehouse privileges.
  • A cloud event does not reach Snowpipe.
  • The pipe is paused or references a different path.

Do not respond first by changing ON_ERROR to a more permissive setting. That can hide a contract failure and load incomplete data. Reproduce parsing with a representative file and reconcile rejected rows.

Connectivity or authentication failure

Classify the earliest failed stage: endpoint, DNS, route, proxy, TLS, network policy, authentication method, identity-provider integration, or client version. Record the native driver code and request identifier.

If sign-in succeeds, move to session context and authorization. A later SQL access control error is not repaired by changing DNS or credentials. Check the active role, warehouse, database, schema, and exact privilege chain.

Access denied

Inspect whether the session role is granted to the user and whether it inherits the required database role or object privileges. Querying normally needs warehouse USAGE, container access, and a privilege such as SELECT on the object.

Avoid granting ACCOUNTADMIN as a diagnostic shortcut. Instead, compare the failing role's grants with the minimal required path and correct the missing link.

Slow query or unstable latency

Use Query History to separate provisioning, queueing, compilation, and execution. Open Query Profile and inspect partitions scanned, bytes scanned, row expansion, expensive operators, spill, and network time.

Select remediation from evidence:

  • Queueing across concurrent queries can justify multi-cluster behavior or workload isolation.
  • A resource-bound individual query may justify tested scale-up.
  • Poor pruning may require SQL or data-organization changes.
  • Spill can indicate memory pressure or an inefficient join or sort.
  • Blocking requires transaction analysis, not a larger warehouse.

Measure credits and workload throughput after the change.

Troubleshooting Workflow

Step 1: Lock identity and scope

Record organization, account, region, user, active role, warehouse, database, schema, object, client, and time zone. Similar names across accounts are a frequent source of false diagnosis.

Step 2: Locate authoritative evidence

  • Loading: stage inventory, copy validation, copy history, pipe status.
  • Connectivity: client logs, request ID, DNS and TLS evidence, login history, policy references.
  • Access: current role and grants to roles, database roles, warehouses, and objects.
  • Performance: query ID, Query History, Query Profile, warehouse activity, blocking evidence.

Step 3: Test the narrowest hypothesis

Use a safe read-only check where possible. List the stage rather than recreating it. Inspect grants rather than adding a broad role. Review queueing before resizing compute.

Step 4: Change the controlling object

Apply the smallest reversible change that addresses the proven dependency. Record the old value, new value, owner, timestamp, and rollback condition.

Step 5: Validate end to end

Repeat the original operation and verify downstream state. A successful connection is incomplete if the application cannot select its data; a successful copy command is incomplete if row reconciliation fails.

Best Practices

  • Use query tags and workload-specific roles or warehouses to improve attribution.
  • Keep clocks and time-zone handling consistent across clients and history queries.
  • Preserve query IDs, filenames, and request IDs in incident records.
  • Maintain least-privilege diagnostic roles with access to required history views.
  • Test runbooks in a non-production account and validate edition-specific interfaces.
  • Define cost and security approval for changes to warehouses, policies, and integrations.

Certification Relevance

COF-C03 spans loading, connectivity, account management, monitoring, and optimization. Cross-layer troubleshooting demonstrates whether those areas form a usable operational model rather than a list of unrelated features.

Authoritative Sources

Conclusion

Reliable troubleshooting follows dependencies from the earliest observable failure to the controlling object. Preserve evidence, test a narrow hypothesis, apply a minimal change, and verify the original business operation and its downstream result.