Is Sigma Computing down?

Databricks Azure East US is degraded services which is affecting Sigma connections and causing query execution failures and timeouts on Databrick warehouse. We are investigating these errors owing to Databricks Azure East US service interruption (https://status.azuredatabricks.net/) and haven't detected an issue other warehouses at the moment. If your Databrick connection in Sigma is experiencing errors, please continue monitoring: https://status.azuredatabricks.net/ Our apologies for any inconvenience caused.

Databricks Azure East US is degraded services which is affecting Sigma connections and causing query execution failures and timeouts on Databrick warehouse. We are investigating these errors owing to Databricks Azure East US service interruption (https://status.azuredatabricks.net/) and haven't detected an issue other warehouses at the moment. If your Databrick connection in Sigma is experiencing errors, please continue monitoring: https://status.azuredatabricks.net/ We apologize for the disruption and will keep this page updated.

Databricks Azure East US has recovered and is now operational. Sigma connections to Databricks Azure East US should no longer experience query execution failures or timeouts, and warehouse connections should be working normally. This was caused by a Databricks Azure East US service interruption (https://status.azuredatabricks.net/). If you're still seeing errors on your Databricks connection in Sigma, please continue monitoring: https://status.azuredatabricks.net/ We apologize for the disruption and thank you for your patience.

The Azure East US Databricks service interruption has been resolved. Sigma connections to Databricks Azure East US are no longer experiencing query execution failures or timeouts, and warehouse connections are working normally. This was caused by a Databricks Azure East US service interruption (https://status.azuredatabricks.net/). If you continue to see errors on your Databricks connection in Sigma, please reach out to us. We apologize for the disruption and thank you for your patience.

We've identified an issue causing edits to existing input tables to fail on certain connections using OAuth authentication when connection was changed from non-OAuth connection. Impact: Some customers are unable to save edits to existing input tables on affected connections. Next Steps: We are reverting the change that introduced this regression and are working to restore writeback on input tables for the affected connections. We will post another update once a fix has been deployed. We apologize for the inconvenience and will continue to update this page as we make progress!

We have reverted the issue, customers can now change their warehouse connection Auth Method without breaking input tables. We are still working to restore writeback on input tables for the affected connections. We will post another update once the input tables have been restored. We apologize for the inconvenience and will continue to update this page as we make progress!

We've identified an issue causing edits to existing input tables to fail on certain connections using OAuth authentication when connection was changed from non-OAuth connection. Our engineering team is now testing a fix in internal environments. We'll share another update once writeback is fully restored. Thanks for your patience! We'll keep this page updated as we progress.

Customers can now change auth methods safely. However we are still restoring the effected customers who are unable to make edits to input tables. We will post another update once the input tables have been restored. We apologize for the inconvenience and will continue to update this page as we make progress!

Customers can now safely change warehouse connection auth method. We are still restoring the impacted customers who are unable to make edits to input tables that were created prior to the auth method change. We will post another update once the input tables have been restored. We apologize for the inconvenience and will continue to update this page as we make progress.

Our engineers have implemented mitigation measures to circumvent the issue and we are monitoring their effect closely. Customers can now safely change warehouse connection auth method and make input table edits.

We applied a mitigation and are monitoring its effect closely. Customers can now safely change warehouse connection auth method and make input table edits. We'll share our next update in 4 hours. Thanks for your patience.

The mitigation measures have proven effective, and the issue is resolved. We will perform a root cause analysis (RCA) and publish our findings in a postmortem note to the Sigma Community site in coming days.

We received reports of errors causing scheduled materializations and exports to fail. This has been resolved now. We will perform a root cause analysis (RCA) and publish our findings in a postmortem note to the Sigma Community site in coming days. Impacted Cloud Regions & Services: azure:production:eastus2 and aws:us-west-2 User Experience: For organizations hosted in the affected regions (aws:us-west-2 and azure:production:eastus2), scheduled materializations and scheduled exports did not run for the duration of the incident. Exports and materializations have since returned to normal operation. Organizations with a high volume of scheduled exports may experience some delayed processing as queued jobs catch up. Incident Start Time: Approximately 12:02 PM UTC Incident End Time: Approximately 1:01PM UTC

We have received reports of errors causing users to be unable to utilize all portions of the Sigma application. We are investigating the issue at the highest priority. Our preliminary investigations indicate the following: Impacted Cloud Regions & Services: organization hosted on GCP User Experience: Unable to load Sigma Incident Start Time: Approximately 3:06 PM UTC We will provide updates on this page in the next 1 hour.

Our engineers are seeing signs of recovery from an outage associated with GCP and related networking failures. We are monitoring the service closely and awaiting confirmation from Google Cloud that the incident is fully resolved before declaring this issue resolved. We will provide another update when we have further information. Impacted Cloud Regions & Services: Sigma users hosted on GCP User Experience: We expect GCP-hosted users starting to be able to load Sigma, open workbooks, or render reports fine Incident Start Time: Approximately 02:46 UTC Sep 1, 2026

This incident has been resolved. Our engineers are seeing services have returned to normal. Multiple customers have confirmed that they can load Sigma successfully. We apologize for the inconvenience and will continue monitoring the service closely. We will perform a root cause analysis (RCA) and publish our findings in a postmortem note to the Sigma Community site in coming days. Impacted Cloud Regions & Services: Sigma users hosted on GCP User Experience: GCP-hosted users will be able to load Sigma, open workbooks, or render reports without any issues. Incident Start Time: Approximately 02:46 PM UTC Sep 1, 2026 Incident End Time: Approximately 05:29 PM UTC Sep1, 2026

**Incident date:** September 1, 2026 **Duration:** Approximately 90 minutes **Affected service:** Sigma organizations hosted in Google Cloud Platform \(GCP\) us-central1 ## Summary On September 1, a Google Cloud networking incident in part of the us-central1 region interrupted connectivity to Sigma services. Customers hosted in GCP us-central1 were unable to reliably access the Sigma application, administration UI, workbooks, and some embedded experiences. No Sigma code or configuration change triggered the incident. ## Root cause During routine maintenance, Google Cloud experienced a network failure in part of the us-central1-b zone. Sigma services in the region had a non-redundant network dependency in the affected zone, so a zone-scoped failure caused a broader service disruption for customers hosted in the region. See the [Google Cloud incident report](https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev) for details about the cloud provider event. ## Resolution Google Cloud restored the underlying network service, and Sigma recovered without a Sigma-side deployment. Customers did not need to make changes to resume using Sigma. ## Corrective actions Sigma is taking the following actions: * Increase network redundancy across affected Sigma services in this region. Other regions are not impacted by the same deficiency as that in us-central1. * Add additional production health monitoring that operates independently of the environment it monitors. * Improve zone-level availability monitoring and alerting for external status pages. * Improve retry and recovery behavior for background workloads \(including materialization\) during transient network failures. We apologize for the disruption and are using this incident to improve the resilience and independent detection of Sigma services.

Between August 28 at approximately 11:47 PM UTC and September 1 at approximately 4:09 PM UTC, scheduled and direct exports displayed number and date columns as text when opened in Excel and Google Sheets. The cause has been identified and resolved. We will perform a root cause analysis (RCA) and publish our findings in a postmortem note to the Sigma Community site in coming days. Timeline Incident start time: August 28, approximately 11:47 PM UTC Incident end time: September 1, approximately 4:09 PM UTC