Key takeaway
An outage event, an interrupted customer and a customer interruption are different units; a restored feeder status cannot substitute for the restoration history.
Choose the interruption population
A utility archive can list three outage incidents and still contain hundreds of customer interruptions. One incident may affect many customers, and the same customer may lose supply more than once. The practical question is whether the retained history can reproduce a declared reliability measure for a defined service population. Start with the customers covered, observation year, sustained-interruption rule and restoration boundaries. A count of closed outage tickets answers a different question.
EIA’s published reliability table distinguishes SAIDI, interruption minutes per customer, from SAIFI, interruption frequency per customer, and CAIDI, restoration minutes per interruption. It also separates all events, events without Major Event Days and loss-of-supply exclusions. Those are reporting definitions, checked 11 October 2026, rather than proof that a company’s archive follows them. Keep the exact scope attached to every calculated figure.
Reproduce a staged restoration
This hypothetical annual record covers a constant population of 100 customers. Event A interrupts all 100 for 30 minutes. Event B later interrupts the same 100: 40 are restored after 20 minutes and 60 after 50 minutes. Event C interrupts 50 for 120 minutes. All interruptions meet the invented local sustained-event rule. The example assumes complete event membership, no overlapping interruptions and valid elapsed-time evidence.
The ledger contains 250 customer interruptions, despite only 100 customers and three event identifiers. Total customer-interruption minutes are 12,800. All-event SAIDI is 12,800 / 100 = 128 minutes per customer; SAIFI is 250 / 100 = 2.5 interruptions per customer; CAIDI is 12,800 / 250 = 51.2 minutes per interruption. Applying Event B’s last restoration time to all customers would overstate its duration.
| Event / stage | Customer interruptions | Duration, minutes | Customer-minutes |
|---|---|---|---|
| A | 100 | 30 | 3,000 |
| B: first restoration group | 40 | 20 | 800 |
| B: later restoration group | 60 | 50 | 3,000 |
| C | 50 | 120 | 6,000 |
| Total | 250 | Different stages | 12,800 |
Preserve the exclusion decision
For a second hypothetical view, the responsible reviewer has already classified C as an excluded major event under the example’s separate policy. Removing its 6,000 customer-minutes and 50 customer interruptions gives SAIDI of 68 minutes, SAIFI of 2 and CAIDI of 34 minutes. The population remains 100. Lower figures here result from a changed scope; no equipment or response improved.
Do not label C a Major Event Day merely because the weather was severe. EIA’s IEEE-method note describes a daily-SAIDI threshold calculated from historical daily values. Preserve the actual classification method, threshold evidence, date and authorizer in the source archive. This illustration does not calculate that threshold or claim IEEE conformity. Keep both inclusive and excluded results so the exception remains inspectable.
Do not average incompatible reporting groups
Recover customer membership and restoration stages before calculating a rollup. Check whether a customer interrupted twice is counted twice in frequency, whether momentary events use a different measure, and whether overlapping source incidents represent one continuous interruption. When customer identifiers must be withheld, an approved aggregate needs enough stage-level counts to reproduce duration without exporting addresses or the network map.
EIA’s technical notes explain customer-weighted aggregation and show that missing reports can change which populations enter different views. An average of two published SAIDI figures is therefore insufficient unless their customer weights and reporting scopes match. For an owner’s historical file, document population changes, absent reporting periods and which denominators were used. Unknown population coverage should remain an unresolved condition, rather than being replaced with the current customer count.
Finish with an evidence decision
The usable deliverable is a scope ledger: event membership, restoration-group duration, customer-interruption count, customer population, exclusion basis and calculation version. In this example, all-event and excluded-event arithmetic are reproducible; a real classification would still require its approved historical method. Assign the missing denominator or classification record to the utility reporting owner before proposing an external evaluation.
Use Inventory to describe these categories and Due diligence to define whether a recipient needs reliability reporting, restoration sequences or only event descriptions. Customer locations and network weaknesses need separate disclosure review. A synthetic ledger can explain the structure at the first discussion. No reliability percentage establishes data value, a receiving program’s interest or authority to provide actual outage records.