Assessing Data Center Grid Risk for Supply Chain AI

The uncomfortable evidence for supply chain AI resilience does not begin with a supply chain planning outage. It begins one layer lower, with large blocks of electronic load disappearing from power systems fast enough to force grid operators and researchers to pay attention.

The first two events are the ones that should stop a planning team from treating power continuity as an abstract facilities issue. In Northern Virginia, the reported July 2024 sequence involved 60 data centers disconnecting and roughly 1,500 MW of load dropping at once after a voltage fluctuation; the region’s broader concentration is also material, with Data Center Alley described as having more than 2.5 GW of active capacity.[1] In Ireland, the May 2025 event was smaller in absolute size but sharper in proportion: 387 MW represented 52% of data center demand at that moment, and EirGrid emergency measures followed.[2]

ERCOT adds a different kind of warning. The Texas A&M and Harvard analysis describes more than 2,600 MW of electronic load tripping during transmission faults, with system frequency reaching 60.4 Hz, where conventional generators may fail to ride through.[3] The same paper points to regional concentration: 15 U.S. states account for about 80% of total data center load, and PJM capacity prices rose from $28.92/MW for 2024/25 to $329.17/MW for 2026/27 as data center load growth intensified demand on the system.[3]

None of this proves that o9, Blue Yonder, Kinaxis, RELEX, Anaplan, or any other planning platform failed because of those grid events. That caveat matters. A buyer should not turn grid disturbance evidence into a vendor accusation without a documented outage record. The practical conclusion is narrower and more useful: the infrastructure beneath cloud planning platforms is now exposed to documented, dated, multi-hundred-megawatt power-system disturbances, and ordinary vendor questionnaires often do not reach that layer.

The Dependency Chain Is Already in the Architecture

A modern supply chain planning workflow can look deceptively software-only from the conference room. Demand sensing refreshes. Allocation logic runs. A planner opens a scenario. An executive waits for an S&OP number. Underneath that sequence is a chain: the planning application depends on a SaaS platform, the SaaS platform depends on cloud regions and data services, those regions depend on physical data centers, and those data centers depend on local and regional power systems.

Public vendor architecture statements are enough to establish dependency, though not enough to establish vulnerability. Blue Yonder describes its platform as running natively on Snowflake’s cloud architecture.[4] Kinaxis describes Maestro as delivered through a SaaS model, with infrastructure resilience depending on cloud-provider data center redundancy.[5] Those statements are relevant because they locate planning operations in cloud infrastructure. They do not, by themselves, say anything conclusive about how either vendor would perform during a power-related cloud disruption.

That distinction is where many evaluations get sloppy. “Cloud-based” is treated as a deployment preference. “High availability” is treated as a resilience answer. “Enterprise-grade” is accepted as a substitute for knowing whether the application can continue across distinct grid regions, whether failover has been tested under infrastructure loss, and whether planners retain a usable operating mode when the primary service is degraded.

For a planning director, the risk is not only a blank login page. It can be a delayed forecast refresh during a promotion cycle, an allocation run that cannot complete before transportation cutoffs, a scenario comparison that disappears just as finance is reconciling supply constraints, or an integration queue that resumes in the wrong operational order. The executive question will be simple: can the team still plan? The root-cause answer may be upstream, but the business consequence lands in the planning process.

What Buyers Should Require Vendors to Disclose

The right response is not to reject SaaS planning tools. It is to move power resilience from the infrastructure appendix into the vendor evaluation record. The normal scorecard still matters: model fit, implementation scope, master-data readiness, integration architecture, usability, security, and commercial terms. The missing dimension is whether the service can withstand the kind of cloud-region and data-center disruption that documented grid events now make credible.

1. Multi-region redundancy across distinct grid regions

The question is not merely whether a vendor uses multiple availability zones. Buyers should ask whether production workloads, data stores, integration services, identity dependencies, and orchestration layers can operate across geographically and electrically distinct regions. If the backup region sits inside the same constrained power market or depends on the same cloud control-plane assumptions, the resilience claim needs more detail.

• Which cloud regions host production, disaster recovery, integration middleware, and analytics workloads?
• Are primary and secondary regions in distinct grid regions, not just separate data center buildings?
• Which components fail over automatically, and which require vendor intervention?
• What recovery point objective and recovery time objective apply to planning data, scenario data, and integration queues?

This is where the Northern Virginia and Ireland cases are most useful. They do not say a specific supply chain platform failed. They do show that a local or regional grid event can remove a large block of data center load quickly. A redundancy answer that does not identify electrical separation is incomplete.

2. SLA language that distinguishes power-related outages

Many SaaS agreements define availability in ways that are too broad to support operational planning. Procurement teams should ask how the SLA treats upstream cloud-provider outages, regional power events, brownouts, curtailment, network partitions caused by grid events, and degraded performance that stops planning runs without making the entire service unavailable.

The contract should also say what happens when the platform is technically reachable but operationally impaired. If users can log in but demand sensing cannot refresh, optimization jobs cannot complete, or ERP integrations cannot process in time for the planning cycle, the business has still lost the service it bought. A generic uptime percentage will not answer that.

3. Disclosed outage and incident history

Public sources did not provide vendor-specific SLA provisions for power-related outages across o9, Kinaxis, RELEX, Anaplan, or similar planning platforms. That absence should not be filled with assumptions. It should become a diligence request.

• Provide a history of material service incidents affecting planning, optimization, analytics, integration, or identity services.
• Identify whether any incidents were caused by cloud-region failure, data center power events, utility interruptions, or emergency curtailment.
• Describe customer notification timing, incident classification, and post-incident corrective actions.
• Separate production-impacting outages from internal maintenance, planned downtime, and non-customer-facing infrastructure events.

A vendor that has never had a public power-related outage may still have a strong answer. The useful evidence is not the absence of a headline; it is the presence of tested failover, disclosed incident handling, and clear customer-facing commitments.

4. Degraded-mode planning capability

Some planning processes need full platform performance. Others need enough continuity to keep the business from freezing. Buyers should identify which workflows require real-time cloud execution and which can tolerate a degraded mode for a limited period.

This part is often more operational than technical. A degraded mode may be a read-only planning snapshot, scheduled exports to controlled storage, a fallback integration queue, or a documented manual procedure for the few decisions that cannot wait. The point is to define it before the incident, not to improvise it while executives are asking why the plan has not refreshed.

Curtailment Changes the Question

One reason this issue belongs in vendor evaluation is that data center operators are no longer planning only for rare failures. Google has signed contractual agreements with utilities to curtail AI workloads during grid stress, according to reporting cited in the Texas A&M and Harvard analysis.[3] That does not mean a supply chain planning workload will be curtailed, or that a vendor using public cloud infrastructure will necessarily lose service during a grid-stress event. It does mean that compute demand and grid operations are being actively negotiated, not assumed away.

Supply chain teams should therefore ask vendors how planning workloads are prioritized inside the cloud architecture. A batch training job, an analytics experiment, a sandbox environment, a live demand-sensing refresh, and a production allocation run do not have the same business consequence. If the platform depends on elastic compute during critical windows, buyers should know whether capacity is reserved, how job queues behave during constraint, and which workloads are allowed to slow first.

The answer may be reassuring. Mature SaaS vendors can design around these problems with multi-region deployment, workload prioritization, replicated data stores, tested recovery procedures, and clear customer communication. But those design choices are not proven by the phrase “secure cloud.” They have to be described.

Add a Fifth Dimension to the Vendor Scorecard

A practical evaluation record should treat cloud infrastructure power resilience as its own dimension, alongside functional fit, integration, security, commercial terms, and implementation risk. It does not need to dominate the decision. It does need to be visible enough that a planning director can explain what was checked before the contract was signed.

The documented grid events do not justify panic buying, platform avoidance, or unsupported claims about named vendors. They do justify better questions. When 60 data centers can disconnect in one region, when 52% of a country’s data center demand can drop during a fault, and when multi-gigawatt electronic-load trips appear in grid research, power continuity is no longer someone else’s appendix. It is part of supply chain AI due diligence.

References

1. Data Centers and the Grid: The Growing Challenge of Powering AI, Belfer Center, February 2026, link
2. Data center load drops and grid stability, Schneider Electric Blog, February 2026, link
3. arXiv:2509.07218v3, arXiv, September 2025, link
4. Data Cloud and Platform, Blue Yonder, 2026, link
5. Data Centers, Kinaxis, 2026, link