SteadyState Data Talk to Us

Electric Reliability Council of Texas Initial market

ERCOT market data

SteadyState Data builds automated pipelines around public ERCOT market data for trading, analytics, storage, generation and energy technology teams.

The focus isn't downloading a file. It's making the data usable.

  1. ERCOT
  2. Collection
  3. Validation
  4. Normalization
  5. Database, files or API
  6. Trading, analytics or reporting
Discuss an ERCOT Data Requirement See Example Use Cases

ERCOT pipelines are available now as custom implementations, built around the datasets your team needs. Standardized ERCOT datasets are being developed; until one is running in production, we build it as part of a custom implementation rather than sell it as a ready-made feed.

Market data collection.

Pipelines can be built around ERCOT's public API, Market Information System (MIS) reports and other published market data — collected on a schedule, retried when a source is slow, and checked against what should have arrived.

Prices

  • Settlement point prices
  • Locational marginal prices (LMP)
  • Day-ahead market (DAM) data
  • Real-time market data

Grid conditions

  • Load
  • Generation
  • Outages
  • Transmission constraints
  • System conditions

Nodes and settlement points

  • Resource nodes
  • Load zones, such as LZ_HOUSTON
  • Trading hubs, such as HB_NORTH
  • Node and settlement point mappings

Notices

  • Market notices
  • Operational messages
  • Notices with effective dates

These are the categories ERCOT pipelines are commonly built around, not a catalogue of ready-made feeds. Which datasets a pipeline collects is decided with each client.

Making it usable

Validation and normalization.

Most of the work in an ERCOT pipeline happens after the download. These details decide whether the data can be trusted in a model.

  • Hour-ending time and daylight saving

    ERCOT reports use hour-ending intervals and flag the repeated hour when daylight saving time ends. Timestamps are stored unambiguously, so no hour is double-counted or lost.

  • Different granularities

    Day-ahead prices are hourly, real-time settlement point prices are 15-minute, and SCED runs roughly every five minutes. Normalized tables keep the interval explicit instead of blending them.

  • Reports that change

    ERCOT adds, revises and retires reports as market rules change. A pipeline should detect a format change and stop, not quietly load the wrong columns.

  • Late and corrected data

    Some data posts late, and some is republished after corrections. Validation checks that every expected interval arrived, and handles corrections deliberately.

  • From zip files to tables

    Many ERCOT reports arrive as zipped CSV or XML files. They land in consistent, typed tables built for SQL, Python and notebooks.

Notifications

ERCOT market and operational notifications.

Market notices and operational messages can be collected automatically and routed into the systems a team already watches. This is work we have built before — a lot of important market information arrives this way, and it is easy to miss.

  1. ERCOT notification
  2. Collector
  3. Categorization
  4. Deduplication
  5. Slack, database or alerting system

What can be collected

  • Implementation notices
  • Generation alerts
  • Operational messages
  • Market notices
  • Events with effective dates
  • Events with open and close periods

Why it matters

A notice about a change that takes effect next month is easy to lose in an inbox. Once it is collected, categorized, deduplicated and stored with its effective date, it can be routed to the people who need it — and queried later, when someone asks what changed.

Get the data where you need it.

Delivery architecture depends on dataset volume, update frequency and client requirements. Five-minute nodal prices across every settlement point are a very different problem from a single daily report.

  • PostgreSQL

    Normalized tables in a database your team can query directly from SQL or Python.

  • CSV and scheduled files

    Files delivered on a schedule, in the layout your tools expect.

  • REST API

    An API over the collected data for internal services and applications.

  • Object storage

    Raw and processed files kept in cloud storage for replay and audit.

  • Custom database

    Loading into the database you already run, when PostgreSQL isn't the right fit.

  • Your cloud environment

    Pipelines deployed inside your own cloud account, when the data needs to stay there.

Example use cases.

Build an ERCOT historical database

Collect selected ERCOT datasets continuously and maintain an internally controlled historical database.

Feed trading models

Normalize selected market data into schemas designed for Python, notebooks, quantitative models or internal services.

Automate recurring reports

Retrieve recurring ERCOT reports automatically and load them into databases or analytics systems.

Monitor market notices

Collect, deduplicate and route market notifications into Slack, email or other internal workflows.

Backfill historical data

Build controlled backfill processes for datasets that need historical reconstruction.

Reconcile market data

Validate that expected files, records or reporting periods arrived, and alert when something is missing.

Architecture

Infrastructure, not a file download.

A typical ERCOT pipeline, conceptually. The details change with each client; the shape usually doesn't.

  1. ERCOT public sourcesAPI, MIS reports, notices
  2. SteadyState collectorsScheduled, retried, logged
  3. Validation and normalization
  4. Client data store
    • PostgreSQL
    • CSV / files
    • API
    • Cloud storage
  5. Trading, analytics and reporting

What the client ends up with

  • Historical market data in a store your team controls
  • Schemas designed around how the data is actually used
  • Monitoring that notices missing or late data
  • Delivery that can change without re-collecting everything

We build the infrastructure. We don't resell a CSV.

Engineering guides

ERCOT engineering guides

Building an ERCOT collector is relatively easy. Operating one reliably is where the engineering starts.

Our ERCOT guides cover practical issues including rate limits, missing data, publication latency, retries, historical backfills and production deployment.

API

Building a reliable ERCOT API pipeline under rate limits

Why ERCOT API 429s appeared in March 2026, and how to collect in small, resumable windows without hardcoding limits.

Read the guide

Data Quality

How to detect missing ERCOT market data before it reaches your models

Validate ERCOT datasets for missing intervals and entities, repair only the gaps, and promote only verified periods.

Read the guide

API

Getting started with the ERCOT Public API in Python

Registration, authentication, a first request, pagination, and the pieces a collector needs to run unattended.

Read the guide

Data Quality

Why ERCOT API data can lag behind ercot.com

What ERCOT has said about publication lag, and how to tell late data from missing data.

Read the guide
View All ERCOT Engineering Guides

Need this data running reliably?

SteadyState Data builds and operates focused power-market data pipelines for trading, analytics and energy teams. Start with the market, dataset and delivery method — we'll help determine the smallest reliable system required to get it into your environment.

Discuss an Energy Data Project

Working in another market? See all energy markets.