On this page
Need the current incident state? Open live Snowflake status or Snowflake's official status page. This guide covers the next step: deciding whether a failed query matches a regional incident or a warehouse, account, or workload problem.
A suspended warehouse is not automatically an outage. Snowflake can resume a warehouse for a query when auto-resume is enabled, and queries can queue when available compute is already busy. Snowflake warehouse overview
Is Snowflake Down Right Now?
Check these in order:
- Statusfield — Snowflake status — reported Snowflake status and incident history, with the latest observation time.
- Snowflake's official status page — status.snowflake.com shows active incidents by cloud region (AWS, Azure, GCP) and deployment.
- Twitter/X — search
snowflake downorsnowflake queries failingsorted by Latest. Data engineers post immediately when pipelines start breaking. - Snowflake Community — community.snowflake.com has real-time reports from users experiencing the same issue.
Snowflake Components That Can Fail Independently
Snowflake incidents are often cloud-provider and region-specific. An incident may only affect AWS US-East, not Azure West-Europe:
| Component | What breaks when it fails |
|---|---|
| Query execution | SQL queries time out or return SQL execution error; warehouses can't complete work |
| Virtual warehouse startup | Warehouses fail to resume from SUSPENDED state; queries queue indefinitely |
| Snowpipe / data loading | Automated data ingestion via Snowpipe stops processing new files |
| Replication / Failover | Cross-region data replication falls behind or stops |
| Data sharing | Reader accounts and outbound shares become inaccessible |
| Web UI | Snowsight fails to load or sessions expire unexpectedly |
| Login / Authentication | SSO or password authentication fails; JDBC/ODBC connection refused |
| REST / SQL API | Programmatic queries via REST API or JDBC/ODBC drivers fail |
Check the Warehouse Before Declaring an Outage
Review query history and warehouse load alongside the regional status report. Snowflake distinguishes queries waiting for compute provisioning, queries queued by load, and queries blocked by a transaction. Those states call for different responses; a timeout alone does not identify a vendor incident. Monitoring warehouse load
Capture the query ID, error text, warehouse, region and observation time before changing your setup. If the connection fails before you can run SQL, use your saved account details and the official regional incident report.
The Data Pipeline Dependency Risk
Snowflake outages cascade quickly into downstream systems: BI dashboards show stale data, dbt models fail to run, and business reports miss their SLAs. Unlike application outages that affect end users immediately, data outages often surface hours later — when a morning dashboard doesn't update or an ETL job silently fails overnight.
Mitigation strategies:
- Retry with backoff on query failures — transient Snowflake errors often resolve in seconds; implement retry logic in dbt, Airflow, or your pipeline framework before treating it as an outage
- Monitor warehouse resume time — compare delays with your normal workload and inspect provisioning or queueing before attributing them to a regional incident
- Use multi-cloud or multi-region accounts — Snowflake supports account failover to a secondary region; configure Business Continuity if uptime SLAs are critical
- Cache BI layer results — configure your BI tool (Tableau, Looker, Metabase) to cache query results; dashboards stay usable during short Snowflake incidents
- Decouple ingestion from transformation — use a staging layer (S3, GCS, ADLS) as a buffer; Snowpipe loads from the staging layer when Snowflake recovers, minimizing data loss
- Monitor independently — use Statusfield to detect Snowflake incidents before your data team's morning standup turns into a war room
How Snowflake Handles Incidents
Snowflake publishes affected services and regions on its official status page. Match those details to your account and read the latest update. Avoid predicting recovery from a typical duration: the incident record and your own checks determine when it is appropriate to resume work.
What to Do During a Snowflake Outage
- Identify your account's region — run
SELECT CURRENT_REGION()in Snowflake and check status.snowflake.com for that specific region - Check ACCOUNT_USAGE views — query
SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORYto see if recent queries haveERROR_MESSAGEpopulated; confirm the failure pattern - Test with a simple query — run
SELECT CURRENT_TIMESTAMP()to isolate whether the connection layer or query execution is failing - Pause ETL pipelines — if Snowflake is confirmed down, pause Airflow DAGs or dbt Cloud runs to prevent cascading failures and noisy alerts
- Communicate SLA impact — notify business stakeholders immediately if morning reports will be delayed; set expectations before they start asking
- File a Snowflake support ticket — even if the status page shows an incident, open a ticket with your account locator and error details for faster triage
- Resume pipelines incrementally — when Snowflake recovers, restart pipelines with incremental loads rather than full refreshes to avoid overwhelming your warehouses
For a repeatable escalation process, use the third-party outage runbook.
Monitor Snowflake Automatically
Monitor Snowflake on Statusfield to follow reported provider status alongside your own query and pipeline monitoring. Configure relevant monitors and supported notification channels; provider publication, polling, and delivery settings affect when an alert can arrive.
Keep your vendors in view.
Choose from 7,000+ services, follow the components you use, and configure alerts for your team.
Try any paid plan for 30 days, no credit card required. Free trial for first-time customers.