SPP · Load

SPP system load

Name: SPP system load
Creator: Dryos

Load every five minutes in SPP's RTO and in RTO West, with SPP's own short-term forecast for each interval beside it.

spp-system-loadevery 5 min · 5m rows2 entities

SPP

38,727MW

2026-09-15 13:45 UTC

SWPW

2,709MW

2026-09-15 13:45 UTC

Read from the Dryos API and cached for an hour; the stream itself updates every 5 min.

What is in it

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

LoadMW
Actual load in the interval.
load_mw
Short-term forecastMW
SPP's short-term forecast for the same interval.
stlf_mw

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

Column	Type	Description
interval_start_utcrequired	timestamp	Start of the five-minute 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_mw	number	Actual load in the interval, MW.e.g. 50208
stlf_mw	number	SPP's short-term load forecast for the interval, MW.e.g. 50355
source_published_at_utc	timestamp	When SPP published the row.
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-system-load/query?node=SPP&limit=12"

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

shell

curl "https://api.dryos.ai/v1/datasets/spp-system-load"

Hourly averages for the last day

shell

curl "https://api.dryos.ai/v1/datasets/spp-system-load/query?node=SPP&start=-24h&interval=1h&agg=avg"

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 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 system load 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 · STLF 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 every 5 min; 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.