Outage communication: maps, restoration estimates, and proactive alerts

Reference article · 5 min read

During an outage, a utility's website and phone line become the public face of the organization. Customers want three answers: that the utility knows, some sense of when service will return, and confirmation when it is back. Map polish matters far less than whether those answers are current and identical on every channel.

Outage communication is also a governance matter. The map renders the outage management system, which is fed by SCADA and meter data, field reports, and trouble calls. When a link in that chain lags or disagrees, the public sees the disagreement before staff do. What follows covers what to publish, how to publish it without over-promising, and what to settle before a procurement closes.

What the map shows and how often it changes

Write down what a marker on your map represents. Most disputes with customers and elected officials trace back to an unstated assumption.

Refresh cadence. Pick an interval, publish it on the page, and stamp every view with the time of the last successful update. A map that silently serves stale data during a communications failure is worse than one that says it is stale.
Aggregation level. A pin on a single service address can reveal which homes are empty and may conflict with state rules on customer information. Aggregate to a boundary with local meaning, such as a feeder area or ZIP code, and suppress groupings below a minimum affected-customer count. Confidentiality rules vary, so confirm yours with counsel.
Nested outages. A customer restored at the substation level may still be out because of a downstream device or a service drop. Decide whether the map shows the parent case, the child case, or both, because customers whose neighbors have lights will call.
Planned work. Scheduled outages should be visually distinct, posted in advance, and given their own notification path.
Cause codes. Keep a short plain-language public list and map internal engineering codes onto it.

Restoration estimates without over-promising

Estimated restoration time is the most requested and most damaging field on the page. Treat it as a state machine, not a number.

Publish an explicit assessing state before any estimate exists, and say what it means. Label storm-wide estimates as system targets rather than commitments for one address, and reserve case-level estimates for cases a crew or damage assessor has reported on. Expire estimates automatically once they pass, because a time visibly in the past reads as neglect. When an estimate changes, show that it changed rather than quietly swapping the value.

Proactive alerts

Alerts turn a passive map into service. The event set is small and worth specifying precisely: outage detected at the premise, estimate assigned, estimate revised, restored, and still out after a parent case closes.

Contact data. Alerts are only as good as the link between account, premise, and phone or email. Plan the reconciliation work between the customer information system and the notification platform, including landlord and tenant accounts.
Consent rules. Automated calls and texts are subject to federal and state requirements that change over time. Have counsel confirm current consent, opt-out, and record-keeping obligations before launch, and retain enrollment evidence.
Volume control. Require batching, per-customer rate limits, quiet-hour handling with a documented exception for safety notices, and an operator kill switch.
False restoration. Systems sometimes report power restored when it is not. Decide in advance how a premature all-clear is corrected and who authorizes it.

A status page that survives the traffic

Peak traffic arrives in the same minutes as the event, and the common failure is a page that queries the outage management system live, then collapses and degrades the system behind it.

Publish snapshots instead: have the outage management system write a small data file on a fixed cadence to storage served by a content delivery network, and render the map from that file. Keep the page on infrastructure separate from billing and account login. Provide a low-bandwidth text listing as a fallback, meet the accessibility requirements that apply to your agency, and translate the page into the languages your service area uses. Load test against your worst historical event.

Keeping the call center and IVR on one story

The map, the interactive voice response system, agent screens, and social posts should draw from the same snapshot, with agents seeing extra internal detail rather than different public facts. Confirm that the IVR can accept an outage report, that it reads the same estimate the map shows, and that it fails to a staffed queue rather than a dead end. Public information officers should be able to post a short message without a code deployment.

After-event reporting and what to require

Boards and commissions ask how an event was handled, not only how long it lasted. Retain map snapshots and the notification log so the record can be reconstructed, and assume some of it is subject to public records law.

Reliability indices are commonly calculated using the definitions in IEEE Standard 1366, which also describes an approach to classifying major event days. Reporting obligations differ by state and utility type, so confirm what your regulator or governing body expects.
Ask vendors to demonstrate a live failover of the public map rather than describe it, and to state measured peak page and message throughput.
Require in the contract: your data in an open format on demand and at termination, a documented refresh interval with alerting when it is missed, published interface specifications for the systems involved, surge capacity terms, and accessibility conformance evidence.
Rehearse before storm season. A tabletop exercise that walks a nested outage, a bad estimate, and a false restoration through every channel finds more defects than another demonstration.

HQT works with state and local agencies on systems integration and public-facing applications of this kind.

Frequently asked questions

How often should a utility outage map refresh?

There is no universal standard, so the utility sets an interval it can sustain during its worst event and publishes that interval on the page. What matters more than the number is showing the time of the last successful update on every view, so a stalled feed is visible rather than silently presented as current. Pick a cadence the outage management system and the hosting path can hold under peak load, then verify it in a load test.

Should we publish estimated restoration times if we are not confident in them?

Yes, but only as clearly labeled states. Show an assessing status before any estimate exists, distinguish system-wide storm targets from case-level estimates tied to a crew or damage assessment, and expire estimates automatically once the time passes. An estimate that is visibly in the past does more reputational damage than an honest assessing label.

Does publishing an outage map raise customer privacy concerns?

It can. Pinpointing individual service addresses may reveal which properties are unoccupied and may conflict with state rules governing customer account information. Most utilities aggregate to a larger boundary and suppress any grouping below a minimum affected-customer count. Because confidentiality rules vary by state and by utility type, confirm the applicable requirements with your counsel before choosing a display level.

How do we keep the outage page online when everyone loads it at once?

Do not let the public page query the outage management system directly. Have the system publish periodic snapshot files to storage fronted by a content delivery network, render the map from those snapshots, and host the page separately from billing and account login. Add a low-bandwidth text fallback and load test against your worst historical event rather than typical traffic.

What should we report to our governing board after a major outage?

Boards generally want both restoration performance and communication performance. Reliability indices are commonly calculated using the definitions in IEEE Standard 1366, which also addresses classifying major event days, though reporting obligations differ by state and utility type. Pair those figures with communication measures you can support from your own logs, such as map availability, notifications delivered, and how estimates changed over the event.