Every new solar farm, battery, wind project, gas plant and large load (data centers, chip fabs, hydrogen) has to file an interconnection request with its grid operator before it can connect. The queues are public. For anyone selling into energy construction, they are a pipeline list: project size, location, developer, status and the date the developer expects to come online.
The problem is that each operator publishes its queue differently.
Why combining queues is tedious
- Each ISO uses its own spreadsheet layout, sheet names and column headers.
- Fuel types and statuses are coded, and the codes differ by operator. NYISO, for example, uses short codes for both fuel and study status.
- Some files split active, withdrawn and completed projects into separate sheets.
- The file locations and names change with each release.
Doing it by hand
- Download the latest queue file from each operator you care about (CAISO's public queue report, ERCOT's monthly GIS report, NYISO's interconnection queue, SPP's active queue).
- Map each operator's columns to one schema: MW, fuel, state, county, point of interconnection, developer, status, queue date, proposed commercial operation date.
- Decode the fuel and status codes using each operator's own legend.
- Stack the results and keep a column saying which ISO each row came from.
Doing it in one run
I packaged those steps as an Apify Actor: US Power Grid Interconnection Queues. It reads the latest file from CAISO, ERCOT, NYISO and SPP, decodes the codes, and returns one normalised table you can filter by ISO, state, fuel and size, then export to CSV or Excel.
How to read a queue
Most queued projects never get built; many withdraw after studies show what the grid upgrades would cost. Treat a queue entry as a lead to watch, and give more weight to projects with a signed interconnection agreement or a construction start date than to new requests.
Top comments (1)
tr.ee/dev-to