Log in Account Create free workspace Open workspace

Data catalog628

Every grid dataset behind Ask the Grid, published by ATG Data: prices, load, generation, congestion, outages, and the reference layers beneath them, each with its source, coverage, schema, and a live sample.

Published by ATG Data14 markets42 sources

Data catalog

Every grid dataset behind Ask the Grid, published by ATG Data: prices, load, generation, congestion, outages, and the reference layers beneath them, each with its source, coverage, schema, and a live sample.

Datasets

Loading datasets…

Programmatic access

GET /api/v1/datasets →
Agents: append .md to any dataset or category URL for its markdown twin.

Explore Ask the Grid Data

See how to work with your organization’s tables alongside shared grid data in Ask the Grid Data.

Datasets

1–25 of 628

Prices

87

All prices →

Prices datasets
Dataset	Cadence	Coverage	Rows
Southern Hour-Ahead Auction Clearing PricesPublished hour-ahead non-firm energy auction clearing prices for delivery into Southern's balancing area, in USD/MWh. Each source update is retained with its UTC delivery hour, original Central hour-ending label, and acquisition time.	Hourly delivery; 15-minute collection	Not reported	—
Southern Day-Ahead Auction Block PricesPublished Firm-LD and Recall day-ahead energy block auction clearing prices for delivery into Southern, in USD/MWh. Delivery flow date, clearing date, product, and source update are preserved independently. Each price applies to the source's delivery block.	Daily delivery block; 15-minute collection	Not reported	—
ERCOTERCOT LMP by Settlement PointLocational marginal prices from ERCOT's real-time market, published every five minutes by Security Constrained Economic Dispatch (SCED) for resource nodes, load zones, and trading hubs. This table supports observed price levels, rankings, volatility, and basis between settlement points. Why two points separated is in their congestion components (atg.ercot_prices_rt) and the binding constraints joined to atg.ercot_constraint_sensitivities. The official source is ERCOT report NP6-788-CD (Settlement Point Prices at Resource Nodes, Hubs and Load Zones).	5-minute (SCED)	2014–2026	1.23B
ERCOTERCOT LMP by BusLocational marginal prices for each electrical bus in ERCOT, produced by Security Constrained Economic Dispatch (SCED) roughly every five minutes. This is the finest public spatial view of observed ERCOT price variation and supports bus-level ranking, history, and basis analysis. A bus price or price spread alone does not identify a binding constraint, congestion component, or electrical relationship to another entity; those claims require direct component or attribution evidence.	5-minute (SCED)	2017–2026	16.6B
ERCOTERCOT SCED System LambdaERCOT's five-minute real-time system lambda, the system-wide marginal energy component of SCED LMP. For a settlement point or electrical bus in the same SCED interval, LMP minus system lambda is the point's congestion component; ERCOT LMP has no marginal-loss component. This supports point-level congestion rankings and history when joined interval by interval to real-time LMP. Which binding constraint moved a point comes from joining the binding constraints to atg.ercot_constraint_sensitivities.	5-minute (SCED)	2014–2026	2.3M
ERCOTERCOT Day-Ahead System LambdaERCOT's hourly day-ahead system lambda, the system-wide marginal energy component in the cleared Day-Ahead Market. For the same delivery hour and settlement point, day-ahead SPP minus DAM system lambda is the point's cleared day-ahead congestion component. Paired with SCED system lambda and real-time LMP, it supports day-ahead-versus-real-time congestion basis by point. It does not identify a binding constraint's effect on a point without direct attribution evidence.	Hourly (DAM)	2014–2026	109.9K

Ancillary Services

55

All ancillary services →

Ancillary Services datasets
Dataset	Cadence	Coverage	Rows
ERCOTERCOT System Inertia, Frequency and Real-Time ConditionsERCOT system-wide synchronous inertia and frequency from the public Real-Time System Conditions CDR page, one observed snapshot per publication, approximately every minute. system_inertia_mw_s is stored rotating energy in MW·s; divide by 1000 for GW·s. frequency_hz is system frequency in Hz. The same timestamp carries instantaneous time error, consecutive BAAL exceedance minutes, demand, net load, capacity excluding ancillary services, wind and solar. Historical DC-tie columns remain in this table, but the current CDR page no longer publishes them; current signed flows come from ercot.dc_tie_flows via the dedicated DC Tie Flows dashboard. This is the series displayed by ERCOT Radar’s System inertia and System frequency widgets. History accumulates from first ingestion; the upstream snapshot has no historical archive for backfill. It is system-wide, not plant-level or regional inertia, and does not provide inertia forecasts or a current critical-inertia threshold.

Congestion & Constraints

57

All congestion & constraints →

Congestion & Constraints datasets
Dataset	Cadence	Coverage	Rows
ERCOTERCOT SCED Shadow Prices and Binding ConstraintsActive transmission constraint and contingency pairs from ERCOT's Security Constrained Economic Dispatch runs, including the named facilities, MW limits and flows, violations, shadow prices, and the reported maximum shadow price and terminal voltages when available. A positive shadow price establishes economic binding in that SCED interval; a zero shadow price is an active constraint without a marginal system cost. The reported maximum shadow price is a penalty ceiling, distinct from the MW limit. It does not, by itself, identify which settlement point or hub the constraint affected, measure total substation utilization, or explain every contemporaneous LMP separation; those claims require shift-factor or direct attribution evidence. History spans 2014-05 to present. The official source is ERCOT report NP6-86-CD.

Infrastructure

115

All infrastructure →

Infrastructure datasets
Dataset	Cadence	Coverage	Rows
ERCOTERCOT Interconnection QueueERCOT's public large-generation interconnection queue, with project identity, developer, proposed point of interconnection, transmission owner, technology, requested MW, queue status, and proposed or actual completion dates. Each posting is a snapshot, so current project claims must use the latest snapshot rather than count every vintage. Queue inclusion and proposed dates do not establish available transmission headroom, study outcome, approval, construction probability, or an operating asset. The official source is ERCOT's GIS Report.	Monthly snapshot	2006–2026	115.1K

Every dataset in the catalog, by name

628

Prices

Explore Ask the Grid Data

See how to work with your organization’s tables alongside shared grid data in Ask the Grid Data.

ERCOT Constraint Shift Factors (Estimated)Estimated sensitivity of every ERCOT pricing location's price to every binding transmission constraint: one row per constraint, contingency, and location, recomputed hourly over a rolling 60-day window. This is what answers 'which nodes drive this constraint' and 'which constraints is this node exposed to'. Covers ERCOT's transmission constraints with their contingency and both named terminals, over 1,123 settlement points. ERCOT method_version='public-recent-prior-v1' retains a 60-day public-price prior and updates it with seven days of public observations, with an hourly refresh and one-hour input buffer. No official factors or network models enter the estimator. Independently identified factors with at least three binding intervals but fewer than 12 intervals or three binding days have estimation_status='provisional': shift_factor is populated, std_error and node_r2 are NULL, n_resamples is zero, and actual support counts are preserved. Explicitly label these early estimates and exclude them from confidence-ranked results. shift_factor is in the ISO's orientation — POSITIVE means an incremental MW injected at that node increases loading on the constraint and the node is paid below system lambda while it binds; NEGATIVE means generation there relieves the constraint and earns a premium. These are ESTIMATES recovered from the price identity LMP = energy - sum(shift_factor x shadow_price), not a published PTDF matrix. They are measured RELATIVE TO THE MARKET'S REFERENCE — the identity yields SF(node) - SF(reference), so a single absolute value should be quoted as 'relative to the system reference' rather than as the node's PTDF, while DIFFERENCES between nodes are exact because the reference term cancels. Three further differences from a published matrix: they describe a NODE (a generator at that node inherits its location's value, and two units at one node are indistinguishable), they reflect the topology actually in effect across the window including outages rather than a stated base case, and each row with estimation_status='estimated' carries a std_error from a 200-draw block bootstrap that resamples whole days. Read std_error before quoting shift_factor: an estimate whose absolute value is not at least twice its standard error is not distinguishable from zero. estimation_status says why a row has no number — 'thin_support' (in the fit, so it is controlled for, but under 12 binding intervals or under 3 distinct binding days), 'no_support' (under 3 binding intervals; not a regressor), or 'collinear' (it bound in lockstep with another constraint, so the two cannot be separated). Where from_station and to_station are populated they identify the monitored element and are NOT the constrained direction — the sign of shift_factor is what says which way. Every read must pin computed_at to one run, and must resolve that run through the companion atg.<iso>_constraint_sensitivity_runs ledger rather than off max(computed_at) here — rows are written in blocks that all carry the new timestamp, so an unfinished or abandoned run would otherwise look like the newest. Mixing runs averages a node across different network topologies.

CAISO Constraint Shift Factors (Estimated)Estimated sensitivity of every CAISO pricing location's price to every binding transmission constraint: one row per constraint, contingency, and location, recomputed nightly over a rolling 60-day window. This is what answers 'which nodes drive this constraint' and 'which constraints is this node exposed to'. Covers CAISO's INTERTIE AND NOMOGRAM constraints, not internal transmission branches, over roughly 19,400 pricing nodes. CAISO publishes no contingency or terminal names on this feed, so contingency_name, from_station and to_station are always empty. shift_factor is in the ISO's orientation — POSITIVE means an incremental MW injected at that node increases loading on the constraint and the node is paid below system lambda while it binds; NEGATIVE means generation there relieves the constraint and earns a premium. These are ESTIMATES recovered from the price identity LMP = energy - sum(shift_factor x shadow_price), not a published PTDF matrix. They are measured RELATIVE TO THE MARKET'S REFERENCE — the identity yields SF(node) - SF(reference), so a single absolute value should be quoted as 'relative to the system reference' rather than as the node's PTDF, while DIFFERENCES between nodes are exact because the reference term cancels. Three further differences from a published matrix: they describe a NODE (a generator at that node inherits its location's value, and two units at one node are indistinguishable), they reflect the topology actually in effect across the window including outages rather than a stated base case, and each row with estimation_status='estimated' carries a std_error from a 200-draw block bootstrap that resamples whole days. Read std_error before quoting shift_factor: an estimate whose absolute value is not at least twice its standard error is not distinguishable from zero. estimation_status says why a row has no number — 'thin_support' (in the fit, so it is controlled for, but under 12 binding intervals or under 3 distinct binding days), 'no_support' (under 3 binding intervals; not a regressor), or 'collinear' (it bound in lockstep with another constraint, so the two cannot be separated). Where from_station and to_station are populated they identify the monitored element and are NOT the constrained direction — the sign of shift_factor is what says which way. Every read must pin computed_at to one run, and must resolve that run through the companion atg.<iso>_constraint_sensitivity_runs ledger rather than off max(computed_at) here — rows are written in blocks that all carry the new timestamp, so an unfinished or abandoned run would otherwise look like the newest. Mixing runs averages a node across different network topologies.

MISO Constraint Shift Factors (Estimated)Estimated sensitivity of every MISO pricing location's price to every binding transmission constraint: one row per constraint, contingency, and location, recomputed nightly over a rolling 60-day window. This is what answers 'which nodes drive this constraint' and 'which constraints is this node exposed to'. Covers MISO's binding real-time constraints over its hub and zone roll-up of roughly 325 pricing locations, so the answers are coarser than a full nodal set. MISO publishes no contingency or terminal names, so contingency_name, from_station and to_station are always empty. shift_factor is in the ISO's orientation — POSITIVE means an incremental MW injected at that node increases loading on the constraint and the node is paid below system lambda while it binds; NEGATIVE means generation there relieves the constraint and earns a premium. These are ESTIMATES recovered from the price identity LMP = energy - sum(shift_factor x shadow_price), not a published PTDF matrix. They are measured RELATIVE TO THE MARKET'S REFERENCE — the identity yields SF(node) - SF(reference), so a single absolute value should be quoted as 'relative to the system reference' rather than as the node's PTDF, while DIFFERENCES between nodes are exact because the reference term cancels. Three further differences from a published matrix: they describe a NODE (a generator at that node inherits its location's value, and two units at one node are indistinguishable), they reflect the topology actually in effect across the window including outages rather than a stated base case, and each row with estimation_status='estimated' carries a std_error from a 200-draw block bootstrap that resamples whole days. Read std_error before quoting shift_factor: an estimate whose absolute value is not at least twice its standard error is not distinguishable from zero. estimation_status says why a row has no number — 'thin_support' (in the fit, so it is controlled for, but under 12 binding intervals or under 3 distinct binding days), 'no_support' (under 3 binding intervals; not a regressor), or 'collinear' (it bound in lockstep with another constraint, so the two cannot be separated). Where from_station and to_station are populated they identify the monitored element and are NOT the constrained direction — the sign of shift_factor is what says which way. Every read must pin computed_at to one run, and must resolve that run through the companion atg.<iso>_constraint_sensitivity_runs ledger rather than off max(computed_at) here — rows are written in blocks that all carry the new timestamp, so an unfinished or abandoned run would otherwise look like the newest. Mixing runs averages a node across different network topologies.

PJM Constraint Shift Factors (Estimated)Estimated sensitivity of every PJM pricing location's price to every binding transmission constraint: one row per constraint, contingency, and location, recomputed nightly over a rolling 60-day window. This is what answers 'which nodes drive this constraint' and 'which constraints is this node exposed to'. THE DAY-AHEAD MARKET, not real time: this estimate is fitted to day-ahead marginal values against day-ahead nodal congestion and it describes day-ahead congestion. It covers PJM's day-ahead binding constraints with their contingency over roughly 14,450 pricing nodes. PJM names no terminals, so from_station and to_station are always empty. PJM's real-time shadow prices ARE ingested now (pjm_rt_marginal_value, pjm_transmission_limits) and a real-time estimate is fitted separately; it is not this dataset and is not available here, so do not answer a real-time PJM question from this one. shift_factor is in the ISO's orientation — POSITIVE means an incremental MW injected at that node increases loading on the constraint and the node is paid below system lambda while it binds; NEGATIVE means generation there relieves the constraint and earns a premium. These are ESTIMATES recovered from the price identity LMP = energy - sum(shift_factor x shadow_price), not a published PTDF matrix. They are measured RELATIVE TO THE MARKET'S REFERENCE — the identity yields SF(node) - SF(reference), so a single absolute value should be quoted as 'relative to the system reference' rather than as the node's PTDF, while DIFFERENCES between nodes are exact because the reference term cancels. Three further differences from a published matrix: they describe a NODE (a generator at that node inherits its location's value, and two units at one node are indistinguishable), they reflect the topology actually in effect across the window including outages rather than a stated base case, and each row with estimation_status='estimated' carries a std_error from a 200-draw block bootstrap that resamples whole days. Read std_error before quoting shift_factor: an estimate whose absolute value is not at least twice its standard error is not distinguishable from zero. estimation_status says why a row has no number — 'thin_support' (in the fit, so it is controlled for, but under 12 binding intervals or under 3 distinct binding days), 'no_support' (under 3 binding intervals; not a regressor), or 'collinear' (it bound in lockstep with another constraint, so the two cannot be separated). Where from_station and to_station are populated they identify the monitored element and are NOT the constrained direction — the sign of shift_factor is what says which way. Every read must pin computed_at to one run, and must resolve that run through the companion atg.<iso>_constraint_sensitivity_runs ledger rather than off max(computed_at) here — rows are written in blocks that all carry the new timestamp, so an unfinished or abandoned run would otherwise look like the newest. Mixing runs averages a node across different network topologies.

Data catalog628

Data catalog

Datasets

Programmatic access

Data catalog628

Datasets

Prices

Ancillary Services

Congestion & Constraints

Infrastructure

Every dataset in the catalog, by name

Prices

Ancillary Services

Congestion & Constraints

Load

Generation

Interchange

Outages & Grid Events

Infrastructure

Weather

Hydrology

Programmatic access