Status

Filings encoded and pending

A change is filed but not yet in force. The rate served today is the one being billed today; the encoding below starts serving itself on its effective date, with no deploy.

Plans awaiting re-encoding

These are serving rates we already know predate a filing. Shown because you should not have to guess.

13 document(s) across 13 plan(s). A plan appears once per changed document, so the same plan can be listed more than once.

Coverage

Two denominators, because one of them alone would mislead. 79,866,676 of 143,144,185 US residential customers is 55.8%. The same catalogue is 100.0% of the 79,866,676 customers served by the 50 largest utilities by residential customers (49 groups, 53 operating companies), which is where the work has deliberately gone — the country has 1,267 utilities selling residential electricity, and most of them are small municipals and co-ops.

Counted from EIA Form 861, 2024 data year, Sales_Ult_Cust (residential customer count), regenerated 2026-08-31. Customer counts are a census of households served, not of the plans encoded: a utility counts once it has a residential tariff here, whatever else it also files.

2 further utilities are encoded and serving but cannot appear in any of these figures: Oncor (TX, wires only), CenterPoint Energy Houston. Texas is deregulated, so EIA attributes those households to the retailers that sell them energy rather than to the wires company every one of them pays.

Detected changes

Every time a watched rate sheet stops matching the version the served rates were taken from. The monitor compares bytes, so it cannot tell a re-filed rate from a re-rendered PDF - both are real changes to the document and only one needs the rates re-derived. The outcome column says which, and a row that changed no rate is kept rather than hidden.

Showing the 82 most recent of 247. Show 247, or fetch the whole log as JSON from /changes (needs a key).

Source checks, last 90 days

Whether the monitor ran each day. A gap is a day when staleness could not be ruled out. This is not an uptime chart - uptime is the wrong question for a data product. A day counts as checked whether or not anything changed, because a quiet day and a broken monitor must not look alike.

85 of 87 days checked since the first run on 2026-08-19 — 2 day(s) missed: 2026-10-23, 2026-11-13. A missed day is one where staleness could not be ruled out. Hover a cell for the date and how many of the 342 watched sources were checked that day.  ·  The 3 pale cells are days before the monitor existed. They are not misses.

How fast do filings get encoded? (all time)

Time from detecting that a utility filed a change to the served rates being updated. This bounds how out-of-date any figure here can be, and it is computed from the record rather than promised.

Measured over every filing since launch, not the window above. Rate changes arrive roughly quarterly, so a 90-day window would usually contain too few to mean anything - and a median over one sample would look like precision it does not have.

Time from detecting a filing to the encoded rates being updated. Pending means detected and not yet encoded; filings reviewed as changing no rate, those encoded ahead of a future effective date, those already encoded before the source document changed at all, and those read but not yet confirmed by the filed source, are counted separately rather than averaged in.

Why this page exists

Every rate API claims to be current, and from the outside that claim cannot be checked. This one can: the source documents are polled daily, every version is kept, and when a utility files something we have not encoded yet this page says so by name. A status page that can only report good news is marketing.

Browse rates · GET /health returns this page's summary as JSON, without a key. GET /changes returns the change log as JSON, and needs one.