SPP · Load

SPP seven-day load forecast

Name: SPP seven-day load forecast
Creator: Dryos

SPP's hourly load forecast seven days ahead for the RTO and RTO West, every hourly publication kept.

spp-load-forecast-7dayhourly · 1h rows2 entities

SPP

32,591MW

2026-09-25 03:00 UTC

SWPW

3,008MW

2026-09-25 03:00 UTC

Read from the Dryos API and cached for an hour; the stream itself updates hourly.

What is in it

Every value, its unit, and what the source means by it.

Exactly what a request answers with, read from the API rather than written here.

Column	Type	Description
interval_start_utcrequired	timestamp	Start of the hourly interval, UTC. SPP stamps the interval's end.e.g. 2026-09-14T20:45:00Z
isorequired	string	Publishing ISO.e.g. SPP
zonerequired	string	Balancing authority: SPP for the RTO, SWPW for RTO West.e.g. SPP
load_forecast_mw	number	SPP's mid-term load forecast for the hour, MW.e.g. 39176
source_published_at_utcrequired	timestamp	The publication this forecast is from — the file's stamp, SPP's own label for it, in UTC. Every publication is kept, so an interval carries a row per vintage that covered it.e.g. 2026-09-14T20:50:00Z
collected_at_utcrequired	timestamp	When Dryos collected this row, UTC. Stamped by the platform, not the collector.e.g. 2026-09-14T20:51:10Z

Public, read-only, no key and no sign-up. Relative times stay relative, so a URL keeps working.

The newest rows

shell

curl "https://api.dryos.ai/v1/datasets/spp-load-forecast-7day/query?node=SPP&limit=12"

The catalogue entry — every column, its type and the source

shell

curl "https://api.dryos.ai/v1/datasets/spp-load-forecast-7day"

Full parameters — bucketing, aggregation, filters and search — are on the API reference.

The same stream through the Model Context Protocol, so Claude, ChatGPT, Cursor or any MCP client can query it directly.

shell

claude mcp add --transport http dryos https://api.dryos.ai/mcp

Then ask:

What has Load forecast been at SPP over the last 24 hours, and when did it peak?

Setup for every client is on the MCP server page.

A change in the collector is a change in the data. Anyone reading a step in a series is owed the day it moved under them.

2026-09-17
The three-day gap from 2026-09-14 to 2026-09-17 is a collector fault, not a source one. SPP's dated files still hold it, and the runs after this read it back in oldest first.
Every run since the first raised `TypeError: Start and end cannot both be tz-aware with different timezones` while planning which files to read. Postgres hands a stored timestamp back under `Etc/UTC`, which is the same zone as pandas' `UTC` and not the same object, and a range built between the two is refused — a break that could not happen on the SQLite these were written against. SPP had published normally throughout.
2026-09-14
First collected, from SPP's marketplace portal.
Every other operator's load forecast was here and SPP's was not. Reconciled against the live files on 2026-09-14: schema, nulls, primary key, value bands and row counts passed.

Pulled straight from SPP Marketplace Portal · MTLF vs Actual — no reseller in between — and compared against that file before it is served.
Null means the source did not report it — never zero.
A reading lands hourly; the interval timestamp is the start of the interval, in UTC.
SPP publishes on US Central prevailing time, with a UTC column on every row. Every timestamp Dryos serves is UTC.