Grid Interconnection Queues: Proposed Is Not Operating

An interconnection queue is a list of projects seeking a connection process, not a list of power plants already supplying electricity. When reading a technology company's power strategy or an energy startup's pipeline, separate proposed capacity from agreed, built, and operating capacity. The distinction can change how credible a delivery timeline looks.

Berkeley Lab's Queued Up: 2026 edition, published in May 2026, covers generation requests through the end of 2025. It explicitly excludes load interconnection requests and distribution-connected or behind-the-meter projects. That scope matters: the dataset is not a direct measurement of every data center waiting for power.

Follow the project through its stages

A proposed generator may submit a request, undergo studies, receive required upgrade information, enter an agreement, finance construction, and eventually reach commercial operation. The exact process depends on the operator and jurisdiction. Don't assume every project follows a single universal timeline.

At each stage, ask what evidence exists. A queue identifier proves something different from an executed agreement, and an agreement proves something different from completed construction. A company presentation that uses one broad “pipeline” label can combine all those states.

Keep the source and date with the stage. A project can withdraw or change size, technology, location, or expected operation date. An old queue record should not be treated as current operating evidence simply because it remains searchable.

Distinguish generation from demand

Generation requests concern resources seeking to supply the grid. A data center's load request concerns consumption. They interact through the network, but they are not the same dataset or approval. A large generation queue does not by itself establish a particular site's usable power delivery date.

For a data center claim, ask about the site's utility service arrangement, connection work, permitted load, and energization milestones. For a generation claim, ask about the project-specific study and construction status. Keep those questions in separate sections of the review.

Likewise, an agreement to purchase energy does not automatically identify a new physical connection at the customer's building. Understand what the agreement covers and how delivery relates to the existing grid. Avoid converting a commercial statement into a technical guarantee it does not make.

Read capacity units carefully

MW describes power capacity; MWh describes energy over time. Storage announcements often need both values to explain how long the system could discharge at a given power. Do not add unlike units into one headline number.

For example, a hypothetical 100 MW storage system with 400 MWh of usable energy has a four-hour power-to-energy ratio before considering operational constraints. That simple calculation is not proof of its availability, cycling limits, or contribution during every incident.

Also distinguish nameplate capacity from actual output and contracted availability. Weather-dependent generation, outages, maintenance, and network constraints can affect delivery. A planning record should preserve the relevant assumptions instead of treating a nameplate figure as guaranteed continuous supply.

Avoid double-counting the pipeline

One development may appear in a company pipeline, a partner's announcement, and a grid dataset. These are not necessarily three separate projects. Match project identifiers, location, owner, and technology before summing capacity.

Hybrid projects can include multiple components. Understand whether a reported total combines generation and storage and whether the dataset treats them separately. A copied summary may omit those details, making a large total look simpler than it is.

Use a reconciliation table with source, project identifier, reported stage, capacity unit, observation date, and duplicate-match notes. Leave uncertain matches unresolved rather than forcing every row into a clean total. An honest range or unresolved item is preferable to false precision.

Translate uncertainty into a business scenario

For a startup relying on future power access, list the milestones that must occur before revenue begins. Include equipment delivery, site readiness, connection work, testing, and customer acceptance where relevant. Mark which milestones the company controls and which depend on external parties.

Build a base scenario and a delayed scenario using explicitly invented planning assumptions. For instance, model the cash effect of a six-month delay without claiming that six months is the expected grid delay. Separate the cost of waiting from the cost of cancelling or moving the project.

Do not apply an aggregate historical completion rate directly to one named project as its probability of success. Project stage, location, financing, and specific evidence matter. Broad research provides context, not a substitute for project-level diligence.

Questions for an announcement review

Ask which project and operator are involved, what stage has been reached, what remains unresolved, and whether the claimed date is a target or an evidenced commitment. Request a clear explanation of the capacity unit and whether the figure includes other projects.

For redacted announcement revisions, Text Diff can highlight a change from “expected” to “secured” or a shifted delivery date. It cannot verify the underlying connection agreement. Our startup runway scenarios explain how timing assumptions affect cash planning.

Conclusion

Queue data is valuable when you respect its scope and stages. Proposed capacity is not operating capacity, and generation requests are not data center load approvals. Read announcements with project identifiers, dates, units, and milestone evidence before using them in a business decision.