What Happens When the Grid Says No?

Texas just turned capacity planning into an incident-management problem

On August 3, Texas Gov. Greg Abbott ordered the Public Utility Commission of Texas and ERCOT to audit data centers moving through the state's interconnection process. No new data-center project can move forward until the review is complete. ERCOT also paused its review of the first group of projects, known as Batch Zero.

The immediate story is about electricity demand. The operational story is more important for most technical teams: infrastructure assumptions are becoming less stable, and the failure may appear far away from the power system that caused it.

Texas has at least 335 operating data centers, according to The Texas Tribune. Reporting has put the interconnection queue at roughly 474 gigawatts of requests. Whether every project is built is beside the point. The queue already tells us that a familiar planning model is breaking down: request capacity, reserve capacity, and assume the next region or provider will be available when needed.

That assumption is no longer safe.

The risk is not just “we cannot get GPUs”

When leaders hear that data-center connections are being halted, they often translate it into a procurement question: Can we secure enough compute for the next model, feature, or customer cohort?

That is only the first failure mode.

The harder question is what happens after capacity becomes constrained, delayed, more expensive, or geographically unavailable. A service can remain technically online while reliability degrades in ways customers feel immediately:

• Inference requests spill into a secondary region that has lower throughput and higher latency.
• Batch jobs compete with interactive traffic because workload priorities were never encoded in the scheduler.
• A cloud provider's quota increase takes weeks instead of hours.
• A vendor silently changes regional capacity or GPU availability, invalidating a deployment plan.
• Failover succeeds at the network layer but overloads the destination region.
• Cooling, power, or rack-density limits force an operator to reduce usable capacity below the advertised hardware total.

None of these incidents begins with a red “server down” alert. They begin with a capacity model that stopped describing reality.

Capacity is a reliability dependency

We have spent years treating capacity planning as a finance or infrastructure exercise. Forecast demand, buy hardware, reserve cloud resources, and review the numbers quarterly.

AI workloads expose the weakness in that cadence. Their demand is burstier, their hardware is more specialized, and their operating envelope is more constrained. A workload may need a particular accelerator class, memory profile, interconnect, or region. A generic statement such as “we have 30 percent spare compute” may be meaningless if the spare capacity cannot run the workload that is actually growing.

Capacity needs to become an observable reliability dependency.

That means tracking more than CPU utilization and instance counts. Your dashboard should answer questions such as:

• How much usable inference capacity remains by region, model, accelerator type, and latency tier?
• What percentage of requests can be served if the primary region loses 25 percent of its capacity?
• How long does it take to obtain quota, provision nodes, warm models, and restore traffic?
• Which workloads can be delayed, degraded, or moved without violating a customer commitment?
• What happens to queue depth when a provider throttles a dependency for six hours?
• Which vendors, regions, and hardware classes have no practical substitute?

If you cannot answer these questions from current telemetry, you do not have a capacity plan. You have a spreadsheet describing an optimistic scenario.

The monitoring signals that matter before an outage

Traditional monitoring tends to alert on failure after it has happened. Constrained infrastructure requires earlier signals. The goal is to identify diminishing operating margin while there is still time to change traffic, reduce demand, or provision alternatives.

Watch for:

• Sustained growth in queue depth, even while request success rates remain high.
• p95 and p99 latency increases isolated to one model, region, or hardware pool.
• Falling headroom between peak demand and tested failover capacity.
• Increasing time from quota request to usable capacity.
• More frequent provider throttling, placement failures, or capacity-unavailable responses.
• Model warm-up time becoming a meaningful part of recovery time.
• Secondary-region utilization rising without a corresponding incident.
• Cost per successful request increasing because traffic is being routed through less efficient capacity.

These signals should have owners and thresholds. A 10 percent reduction in available capacity may be harmless for one workload and an imminent SLO breach for another. Alerting needs to reflect service impact, not just infrastructure state.

This builds directly on the concern raised in Who Debugs the Code No One Wrote at 3 a.m.?: operational teams need enough context to understand a failure quickly. In capacity incidents, that context must include where the service can run, what it can run on, and how much margin remains.

Test failover as a capacity event

Many disaster-recovery plans test whether traffic can reach a secondary region. That is necessary, but it is not a failover test.

A real test must apply the workload to the destination at a realistic scale. Measure whether the secondary region can handle:

• The expected traffic volume, not just a health check.
• The same model versions and dependency graph.
• Concurrent batch and interactive workloads.
• Model loading and cache warm-up under pressure.
• Rate limits imposed by external APIs.
• The operational actions required from the on-call team.

Then test partial failure. If the primary region loses 20 percent of its capacity, can you shift only the highest-priority traffic? If a provider reduces available accelerators for a week, can you preserve critical paths while delaying background work?

A useful runbook should define degradation before the incident forces the decision. For example:

If inference headroom falls below 20%:
1. Stop non-urgent batch jobs.
2. Route priority workloads to the tested secondary pool.
3. Reduce response size for the low-priority tier.
4. Page the capacity owner and vendor contact.
5. Recalculate recovery capacity every 30 minutes.

The exact thresholds will vary. The discipline does not.

Questions leaders should ask this week

Texas's decision should trigger a review of assumptions, not a debate about whether your company operates in Texas. Capacity constraints can emerge in any region when demand concentrates, suppliers change allocation, or infrastructure projects slip.

Ask your team:

• Which customer-facing services depend on a single region, provider, accelerator class, or vendor?
• What is our tested capacity under a 25 percent reduction in primary resources?
• Which workloads can be paused without creating a second incident?
• How will we know that capacity is tightening before latency breaches the SLO?
• Have we confirmed that our failover region has the required quota and hardware today?
• Who can approve traffic shaping, workload shedding, or emergency spend at 3 a.m.?
• When did we last test the full recovery path with production-like AI traffic?

The most uncomfortable answer is often “we have redundancy, but we have not proved it under load.” That is exactly the answer to resolve before the grid, provider, or vendor resolves it for you.

Reliability starts with usable capacity

Texas has made a regional power constraint visible. The lesson for technical leaders is broader: availability depends on capacity that is provisioned, reachable, compatible, observable, and tested under failure conditions.

Tink helps small teams surface infrastructure drift, capacity pressure, and service problems before they become late-night incidents. The practical next step is simple: map your critical workloads to their real capacity dependencies, then run one constrained-capacity failover test this week.