US Interconnection Queue Tracker: CAISO & ERCOT Queue Data and Change Alerts

Download US power-grid interconnection queues as one clean table, or get only what changed since your last run: new projects, withdrawals, slipped in-service dates and capacity changes. Schedule it daily or weekly and it becomes an alert feed for solar, storage, wind, gas and large-load projects across California (CAISO) and Texas (ERCOT), the two largest US queues for solar, storage and large loads, with no spreadsheets to open and compare by hand.

Who it is for

• Renewable and storage developers watching competing projects, withdrawals and queue positions near a site.
• Data-center and large-load site selection teams looking for where capacity is being requested, withdrawn or delayed.
• Energy analysts and investors tracking pipeline attrition, completion-date slippage and technology mix.
• Consultants and land agents who need a weekly "what changed in the queue" digest for clients.

What you get

One normalized schema for all supported grid operators (ISOs/RTOs). Fields an ISO does not publish are null.

Field	Description
iso	CAISO or ERCOT
queue_id	The ISO's queue / project identifier
project_name, interconnecting_entity	Project name and developer or interconnecting entity, where published
state, county	Location
interconnection_location, transmission_owner	Point of interconnection and transmission owner, where published
generation_type	Technology / fuel as published (for example Solar, Battery Storage, Wind, Gas, Load)
capacity_mw, summer_capacity_mw, winter_capacity_mw	Requested capacity in MW
queue_date	Date the request entered the queue
status	Status as published (for example Active, Withdrawn, Completed)
proposed_completion_date, actual_completion_date	Proposed and actual in-service dates
withdrawn_date, withdrawal_comment	Withdrawal details, where published
record_key	Stable key (ISO:queue_id) used for change detection
raw	Optional: every extra column the ISO publishes (turn on Include ISO-specific raw fields)

Dates are YYYY-MM-DD. Status labels and technology names follow each ISO's own publication and are only partly standardized.

Two modes

Full snapshot. One row per queue project, for every ISO you select, after your filters.

Changes since last run (default). One row per detected change, with the project's details plus what changed.

• The first run per ISO is the baseline. It saves the current queue to your own storage and outputs nothing (and charges nothing). Changes are reported from the second run on.
• Each later run compares the new download with your saved baseline, then replaces the baseline.

change_type	Meaning
new_project	A queue ID that was not in the previous download
withdrawn	Status changed to a withdrawn status
completed	Status changed to completed / in service / operational
status_changed	Any other status change
completion_date_changed	Proposed completion date moved (later or earlier)
capacity_changed	Capacity (MW) changed
generation_type_changed, interconnection_location_changed, project_name_changed	Those fields changed
removed_from_publication	A project that was in the previous download is no longer published (shows the project details saved in your baseline)

Change rows add field, old_value, new_value and change_detected_on.

Filters

All optional, applied to the output (the baseline always stores the full queue, so changing a filter never loses history):

• States (for example TX, CA)
• Technology contains (case-insensitive words such as Solar, Battery, Storage, Wind, Gas, Load)
• Status (for example Active, Withdrawn, Completed)
• Minimum and maximum capacity (MW)
• Queue date on or after

In changes mode the filters apply to the project as it is now (or its last saved values for removed_from_publication).

Sample output

Illustrative example only. Project names, IDs and values below are made up and do not describe a real project.

Changes mode (a slipped in-service date):

{
  "iso": "ERCOT",
  "queue_id": "EX-0001",
  "project_name": "Example Solar Storage",
  "interconnecting_entity": "Example Energy LLC",
  "county": "Pecos",
  "state": "TX",
  "interconnection_location": "Example 345 kV Substation",
  "transmission_owner": null,
  "generation_type": "Solar",
  "capacity_mw": 200.0,
  "queue_date": "2024-01-05",
  "status": "Active",
  "proposed_completion_date": "2028-01-01",
  "record_key": "ERCOT:EX-0001",
  "change_detected_on": "2026-10-05",
  "change_type": "completion_date_changed",
  "field": "proposed_completion_date",
  "old_value": "2027-06-01",
  "new_value": "2028-01-01"
}

Snapshot mode returns the same project fields without the change columns.

A run summary (projects per ISO, changes found, items output, and any ISO that failed) is saved as OUTPUT in the run's key-value store. If one ISO's site is down or changes its format, the other ISOs still run and the failed one is listed in the summary.

How to use

1. Choose Full snapshot (the default: the current queue, filtered) or Changes since last run (an alert feed; the first run only saves a baseline).
2. Select the grid operators and, optionally, filters.
3. Run it once. In changes mode this creates the baseline.
4. Schedule it (daily or weekly) and connect the dataset to email, Slack, Google Sheets or a webhook with Apify integrations.

Scheduling tip: use one schedule per Baseline store name. The baseline lives in a named key-value store in your own Apify account (default interconnection-queue-tracker). If two schedules share a store name they consume each other's baseline and one of them will miss changes. Use a different name for each separate watchlist, for example queue-watch-texas-storage. ISOs refresh their files on their own schedules (some daily, some weekly or monthly), so running more often than daily rarely finds more.

Pricing

Pay per event, so you only pay for rows you receive:

Event	When it is charged	Price
queue-row	One project row in Full snapshot mode (after filters)	$0.001 per row ($1.00 per 1,000)
queue-change	One detected change in Changes mode (after filters)	$0.005 per change ($5.00 per 1,000)

The baseline run in changes mode charges no queue-row or queue-change events. A changes run that finds nothing costs nothing beyond the platform's standard run start charge, if any. Filters reduce what you pay for. Set a maximum charge per run to cap your spend.

If a run reaches your maximum charge the Actor stops outputting for that run and keeps the previous baseline for that ISO, so the undelivered changes are reported again on the next run (some already-delivered changes may repeat). Set a generous cap for scheduled runs.

Data sources, attribution and disclaimer

Each run downloads the current public interconnection-queue publication from each ISO/RTO website, using the open-source gridstatus library (BSD-3-Clause):

ISO	Source
CAISO	California ISO public queue report (PublicQueueReport.xlsx)
ERCOT	ERCOT GIS report, published through the ERCOT Market Information System

Attribution: queue data is published by the California ISO (CAISO) and the Electric Reliability Council of Texas (ERCOT). Please credit the California ISO as the source of CAISO data.

Disclaimer: this Actor is an independent tool, is not affiliated with, endorsed by or sponsored by any ISO/RTO, and uses their names only to identify the data source. Data is provided "as is" without warranty of accuracy, completeness or timeliness. ISOs revise or reformat their files without notice, and this Actor normalizes field names and status labels on a best-effort basis. ERCOT does not guarantee the accuracy of compilations or analyses built on its data, and neither do we. Always confirm material decisions against the ISO's official queue, tariff and procedures. ISO names and logos are trademarks of their owners. You are responsible for complying with each ISO's own terms of use for any further use or redistribution of the data.

Limitations

• Other grid operators (MISO, SPP, PJM, NYISO, ISO-NE) are not included. Their website terms restrict or don't clearly allow commercial redistribution. If you need one of them, open an issue: we'll add it once the operator confirms reuse in writing.
• Upstream format changes. ISOs move, rename or reformat their files without notice. When that happens that ISO is reported as failed in the run summary until the Actor is updated; the other ISOs are unaffected.
• Different ISOs, different fields. Some ISOs do not publish developer, county, withdrawal dates or queue dates for every project. Fields that are not published are null.
• Not every project is in a queue. Distributed generation and projects handled by utilities rather than the ISO may not appear.
• Update frequency is set by the ISO, not by this Actor.
• Change detection compares the fields listed above. Edits to other fields (for example a developer rename) are not reported.

FAQ

Why did my first changes-mode run return nothing? That run created your baseline. It is working as intended and costs nothing for rows. You get changes from the second run on.

Can I get the full current queue once and then only changes? Yes. Run once in Full snapshot mode to get the full table, then run in Changes mode: the first changes run creates the baseline and later runs report differences.

How do I get alerts in Slack or email? Schedule the Actor, then add an Apify integration or webhook on the schedule's runs that sends the dataset items to Slack, email, Google Sheets, Make or Zapier.

Is the data real time? No. It is as fresh as each ISO's own publication, which ranges from daily to monthly, and it is downloaded when your run starts.

One ISO failed. Do I still get the others? Yes. Each ISO runs separately. The failed ISO is listed with an error in the OUTPUT summary, and its baseline is left untouched so nothing is lost for the next run.

I need an ISO or a field that is missing. Open an issue on the Actor page with the ISO and the field you need.

Support

Questions or a missing field? Open an issue on the Actor page. Replies are written, usually within a day.

Built by JYInnovation.