Snowflake outage: what a cloud incident reveals about your dependencies
Snowflake recorded incident INC20000199 between 07:00 and 08:30 UTC, impacting service availability. The Snowflake outage serves as a timely reminder that data processes also require a plan for when the platform fails to respond.
News summary
According to the provider's own status page, incident INC20000199 lasted approximately from 07:00 to 08:30 UTC. We are adhering to this confirmed data: there was a window of degradation followed by recovery. We will not speculate on causes that the provider has not publicly detailed.
An hour and a half may seem brief. It ceases to be so when that window coincides with the overnight loads that feed morning dashboards, the synchronisation supplying an ERP, or the processes calculating prices and stock levels before opening. The impact is not measured in minutes of downtime, but in the chain of delayed processes.
Seintec analysis suggests that in modern data architectures, risk has shifted: it is no longer within the server, but in the chaining of services. A delay at the source propagates to ingestion, transformations, reporting, and the decisions depending on them. Many organisations lack visibility into this chain until it breaks.
There are simple and effective measures. Scheduling retries with exponential backoff prevents a transient failure from leaving a process down all morning. Designing idempotent loads allows for re-launching without duplicating data. Furthermore, alerting based on process delays, rather than just errors, detects the problem before management does.
It is also advisable to decide in advance what happens to information while the service is unresponsive: whether it is discarded, queued, or held in intermediate storage for later reprocessing. This decision, made in advance, saves manual reconciliations.
No provider offers absolute availability, and it is unreasonable to demand it. The reasonable approach is to understand the contracted SLA, identify which internal processes depend on it, and have a documented procedure for the duration of any downtime window.
Source: Snowflake Status / Keboola — 4 September 2026
What happened
According to the provider's own status page, Snowflake's incident INC20000199 lasted roughly between 07:00 and 08:30 UTC. That's the confirmed fact: there was a window of degradation followed by recovery, with the provider not publicly detailing the cause.
Ninety minutes sounds minor until that window overlaps with the overnight load feeding morning dashboards, the sync that feeds an ERP, or the process calculating prices and stock before opening.
What it teaches a mid-sized business
In today's data architectures the risk has shifted: it no longer sits in the server, it sits in the chain. A delay at the source propagates to ingestion, transformations, reports and the decisions that rely on them, and many organisations have no visibility into that chain until it breaks.
No provider offers absolute availability, and it isn't reasonable to demand it. What is reasonable is knowing the contracted SLA and having a written plan for what happens while the service doesn't respond.
What to review
Concrete measures for processes that depend on a cloud data provider:
- Retries with progressive backoff so a transient fault doesn't leave a process down all morning.
- Idempotent loads that allow reruns without duplicating data.
- Alerts on process delay, not only on error, to catch the problem before management does.
- A prior decision on what happens to data while the service doesn't respond: discard, queue or keep for reprocessing.
Frequently Asked Questions
- How long did the Snowflake incident last?
- The provider logged incident INC20000199 with a window of roughly 07:00 to 08:30 UTC. The cause has not been made public in detail.
- Does it make sense to replicate data on another platform just in case?
- Only when the cost of downtime outweighs the cost of duplication. For most SMEs it's more cost-effective to design delay-tolerant processes than to run a second platform in parallel.
- Is the technical cause of the incident known?
- No. The provider confirmed the degradation-and-recovery window but has not publicly detailed the causes.
Concepts mentioned in this article: Cloud · Storage
If your decisions depend on data travelling across multiple platforms, it is advisable to know where the chain breaks. At Seintec, we audit your cloud architecture and its dependencies, proposing specific resilience improvements. Request a cloud audit.
Contact SeintecRelated service
Cloud Services
Cloud services to scale your business.