How accurate are these estimates?
Our independent, county-wide restoration estimates, graded against what actually happened. Unofficial — always follow your utility's guidance.
At a glance
Across 600 scored outages since Aug 17, 2026, median absolute error 1.9 h (54% within 2 h). For 52 time-matched cases, our median error was 1.4 h versus the utility's 1.5 h; ours was lower in 50% of them.
Every error figure is a median absolute error — half the estimates landed within that many hours of the actual restoration. The utility comparison is time-matched — both graded on the same readings against the same restoration.
How close, across the 600 most recent scored outages: 36% of estimates landed within 1 hour of the actual restoration, 54% within 2 hours, 69% within 4. Typical direction of the miss: 0.1 h early — we tend to call restoration sooner than it happens.
Utilities pushed their posted time back at least once in 81% of 59 outages with a posted time (median 4× when they did).
Median error by time into the outage: 2.8 h at 1 h in (n=567) · 2.9 h at 3 h in (n=429) · 2.5 h at 6 h in (n=293). Each figure is a different set of outages — only those that lasted at least that long — so read them as separate cohorts, not one outage sharpening over time (a survivor effect: longer outages dominate the later horizons).
Median error by outage size: 1.9 h for 500-2k customers out (n=244) · 1.7 h for <500 customers out (n=239) · 1.9 h for 2k-10k customers out (n=105) · 6.9 h for 10k-50k customers out (n=10).
Data updated Aug 19, 8:00 PM EDT · methodology 2026-07-29.v2 · new events land ~3 h after restoration holds. Preliminary until the sample grows. Every statistic above except the all-time count is computed over the 600 most recently scored outages — the window the published ledger retains — not all 7,956. The gap between tracked and scored is outages where unscored events made no forecast — too small to publish an estimate for, or restored before one became dependable — so there is nothing to grade.
Related: how often utilities push back their posted restoration times — same ledger, utilities graded.
Method
While an outage is active, the model watches how many customers are out and how fast the number is falling, projects the rest of the recovery forward with the pace easing off as it drags on, since crews clear the easy faults first — and leans on weather and past outages in that area. Recalculated ~every 15 min; independent of the utility. When a utility also posts a time, both are shown, labeled separately.
How we grade
- Typical error — median hours off across all estimates published during an outage. ±3 h means half landed within 3 h of truth. Smaller is better.
- "Restored" (what every grade is measured against) — the moment the county's reported outage count first fell to 10% of its peak or less and stayed there. Every grade above (ours and the utility's) measures against that same moment — "time until most reported outages are restored", not the last single customer.
- Bias — near zero means we don't systematically over- or under-promise.
- First vs final — earliest estimate vs the last one before power returned; shows whether estimates sharpen.
- Effective restoration — the target we grade against: outage count below a small fraction of peak and staying there (~90% recovered), not the literal last customer. Public feeds routinely leave stragglers for hours; the live label says "to restore" and grading uses this endpoint — stated here so the numbers can't quietly flatter us.
Only outages that have fully ended are graded, and we never score an estimate against another estimate. When an outage's recovery never settled, the site showed "no clear recovery yet" — a deliberate non-answer, so nothing to grade (that's why "scored" is smaller than "tracked").
Is accuracy improving as data accumulates?
Error here is normalized by each outage's length — a 5-hour miss on a two-day outage isn't the same as on a five-hour one. Raw hours-of-error mostly tracks how severe that week's storms were, so this is the cleaner way to watch the estimator itself improve; the typical outage column shows whether a cohort was simply harder.
| Cohort (by close date) | Outages | Error ÷ length | Median error | Typical outage |
|---|---|---|---|---|
| Earliest (8/17–8/18) | 199 | 24% | ±1.9 h | ~8 h |
| Middle (8/18–8/19) | 199 | 23% | ±2.3 h | ~10 h |
| Latest (8/19–8/19) | 199 | 21% | ±1.6 h | ~8 h |
Roughly flat so far. Preliminary — a real trend needs weeks of varied storms.
What each number measures
Recent examples from the scored sample
The newest 10 scored events (most recent first — not a curated or representative sample); the aggregate statistics above cover the full sample. Records of individual outages and downloadable datasets aren't part of the public site; contact us about future API access.
| County | Closed | Peak out | Restore took | Our error | Utility's error |
|---|---|---|---|---|---|
| Washoe, NV | 2026-08-19 | 291 | 3.8 h | ±0.3 h | — |
| Susquehanna, PA | 2026-08-19 | 482 | 7.5 h | ±4.1 h | — |
| Jefferson, LA | 2026-08-19 | 1,417 | 6.5 h | ±1.6 h | — |
| 87023 | 2026-08-19 | 1,110 | 8.2 h | ±0.7 h | — |
| Sumter, AL | 2026-08-19 | 805 | 20.3 h | ±4.1 h | — |
| 87060 | 2026-08-19 | 211 | 8 h | ±27.4 h | — |
| 87057 | 2026-08-19 | 322 | 15.7 h | ±1.8 h | — |
| Whatcom, WA | 2026-08-19 | 229 | 19 h | ±1 h utility ±3 h | ±3 h |
| Douglas, OR | 2026-08-19 | 219 | 6 h | ±0.5 h utility ±0.3 h | ±0.3 h |
| Muskegon, MI | 2026-08-19 | 244 | 18.5 h | ±0.7 h utility ±3 h | ±3 h |
Newest 10 of 600 scored. Error = median difference between predicted and actual hours-to-restore across the estimates published during that outage. "—" in the utility column means no official restoration time was posted.