Why ERCOT API data can lag behind ercot.com

“Published by ERCOT” doesn't necessarily mean “available through every ERCOT interface at the same moment.”

That matters when you build systems around high-frequency market data. A downstream process that expects every new interval at an exact wall-clock time will classify ordinary publication latency as missing data — and a team that gets a false alarm every afternoon soon stops reading alarms.

Reliable ingestion has to understand the difference between expected, late and actually missing.

Where this guide sits in the pipeline

1. Source
2. Fetch
3. Raw copy
4. Validate
5. Verify completeness
6. Normalize
7. Promote
8. Client system

What ERCOT has said about the delay

The same question comes up repeatedly on ERCOT's API discussion board: why isn't the newest interval on ercot.com in the API yet? ERCOT staff have answered it several times, and the answers are dated:

• December 2024 (Discussion #68). A user polling a five-minute SCED product at 4:01 PM could only see data through about 3:55. An ERCOT staff reply on December 9, 2024 said data in the Public Data Portal and API could be delayed by up to about 10–15 minutes from when it was produced, because synchronization ran in batches, and that improvements were planned.
• August 2025 (Discussion #104). Asked about NP6-788-CD timing, ERCOT staff replied on August 19, 2025 that there was approximately a 5–10 minute delay from when the report is posted on ercot.com to when it is available in the Public Data Portal UI and API. They described this as the current design, said a project was in flight to bring the two much closer together, and suggested downloading the report files from ercot.com in the meantime.
• October 2025 (Discussion #116, Discussion #68). A user saw SCED timestamps in the API about ten minutes behind the ercot.com data product page, and ERCOT staff pointed to #68. There, an October 28, 2025 staff reply described a release planned for early 2026 targeting delays under five minutes, and a later 2026 release moving to an event-driven architecture intended to bring the API close to ercot.com. For data needed immediately, that reply pointed to ERCOT's EWS web services or automation around the ercot.com HTTPS endpoints.

ERCOT has historically documented publication lag between ercot.com and the Public Data Portal/API for some products — the August 2025 reply described approximately 5–10 minutes for NP6-788-CD under the system architecture at that time. These are descriptions of how the system worked when they were written, not a service-level agreement, and ERCOT has been working to reduce the gap. Check current behavior for the products you depend on, and measure it yourself.

Publication time is not ingestion time

Every interval involves at least three moments: when the market interval happened, when ERCOT published data for it, and when your pipeline received it. Collapse them into one timestamp and you lose exactly the information you need to diagnose a delay — whether it happened upstream, in transit, or in your own pipeline.

Why fixed schedules are fragile

while True:
    fetch_latest()
    time.sleep(300)

A five-minute sleep loop assumes data appears on a fixed clock. When publication runs a few minutes behind, the loop fetches before the data exists, records nothing new, and waits another five minutes — or marks the interval as missing. Tightening the loop doesn't fix it. Polling the same data over and over is the pattern ERCOT staff cited when they described degraded API performance in January 2026, when they asked clients to retrieve only what had changed rather than polling full datasets (Discussion #124).

Define an expected-arrival window

1. The market interval ends
2. Normal publication window
3. Late tolerance
4. Missing-data alert

For each dataset, decide how long after an interval its data normally appears, and how much longer you'll wait before calling it late. Until the tolerance passes, an interval that hasn't arrived is pending. After it passes, the interval is missing and the repair process takes over.

Set these windows from your own ingestion logs rather than numbers in a forum thread — including the ones on this page. The distribution of arrival delays per product is one of the most useful things a collector can record, and it tells you immediately when an upstream change makes data faster or slower.

Store source timestamps separately

market_interval   -- the interval the value describes
published_at      -- when ERCOT published it, where the source provides this
ingested_at       -- when your pipeline stored it

Where a report or endpoint exposes a publication or posting time, keep it as its own column. With all three you can chart publication lag per product, see when it changes after an ERCOT release, and show whether a “late” interval was late upstream or late in your own system.

Late versus missing

Late data needs patience; missing data needs repair. Mixing them up wastes effort both ways: alerting on every late interval trains people to ignore alerts, and waiting indefinitely on an interval that will never arrive leaves a silent gap in history. The completeness ledger in detecting missing ERCOT market data tracks both states per dataset and day.

When alternate publication channels matter

For some time-sensitive products, ERCOT staff have pointed users to other channels: downloading the report files from ercot.com for NP6-788-CD in August 2025, and EWS or the ercot.com HTTPS endpoints in October 2025. That doesn't mean files are always faster, or that the API will always lag — it depends on the product and on changes ERCOT makes over time. Choosing a source per dataset, and sometimes using more than one, is a design decision in its own right: see ERCOT API vs file downloads.

Practical takeaway

• ✓Treat published delay figures as dated observations, not guarantees.
• ✓Measure arrival delay per product from your own logs.
• ✓Give each dataset a normal window and a late tolerance before alerting.
• ✓Store market interval, publication time and ingestion time separately.
• ✓Don't fix latency by polling harder; fetch what changed.