Recovering an Unattended Dashboard After a Connection Failure
Recovery is complete when the display shows authorized, current and correct business information. During an outage, identify stale data. After reconnection, validate the session and reconcile the latest state. Browser exits and device restarts need a separate terminal launch mechanism. Test these paths separately; a scheduled page refresh cannot cover them all.
On this page5 sections
Distinguish a running page from a working data service
A rotating dashboard may only be playing local animation. A connected network indicator does not prove that the business API is reachable. The HTML standard's guidance on navigator.onLine warns that it is not a reliable test of actual connectivity. Monitor business request results, the timestamp of the last valid data and whether the interface can still apply updates.
Record three milestones separately: page started, service connected and data updated. Consider a hypothetical energy display that still shows morning readings. A green connection indicator in the afternoon does not establish recovery; check the reporting period and selected area as well. If the source has stopped updating, retain a stale-data indication.
Decide what each module shows during an outage
The business use determines whether an old value may remain visible. Presentation material can continue, while a status used by operators needs a clear freshness indication. Do not turn an unreadable value into zero or show “no alarms” when the alarm service is unavailable.
| Content | Suggested outage behavior | Check before resuming |
|---|---|---|
| Business or energy totals | Keep the last valid value and its timestamp | Reporting period and filters still match |
| Equipment and alarms | Mark status as unconfirmed, rather than all clear | Current state and outstanding alarms |
| Images and static scenes | Continue with resources already available locally | Resource version and completeness |
| Acknowledgment or dispatch | Indicate an unconfirmed operation and prevent duplicate submission | Whether the server received the previous request |
Validate identity and state before resuming normal display
Define a recovery sequence: validate access, load the current business snapshot, resume updates and then remove the stale-data indication. If snapshots and live messages arrive in parallel, reconcile them using the version or sequence defined by the API. An older message must not overwrite a newer state. Repeated reconnection must not create multiple subscriptions that duplicate the same alarm.
Give retries a delay and a defined policy. RFC 6455's abnormal-closure guidance recommends backoff to avoid clients repeatedly reconnecting immediately. A project can use increasing delays with random variation. An authentication failure requires controlled renewal or intervention, rather than endless retries against a disabled account.
Restore only the agreed page, presentation position or business area. Do not automatically replay unconfirmed control actions. Whether acquisition services recover missing records belongs to the industrial data integration design, not to a browser attempting to infer them.
Plan browser restart and cached startup separately
A page that reconnects cannot necessarily relaunch a closed browser. Microsoft's Edge kiosk documentation states that its idle-timeout option does not restart Edge after closing it; a separate mechanism such as Assigned Access is needed. Confirm the approach on the actual operating system and terminal management policy.
Assign startup and process relaunch to the terminal management owner, page and data recovery to the application team, and session renewal to the identity owner. Repeated browser failures should leave a record and notify staff; endless restarts should not conceal resource or release problems.
Test first launch without a cache, an outage with cached resources and restart after a release. When Service Workers are used, Chrome's lifecycle guidance explains how a new worker taking over an old page can affect resources loaded later. Release the page, scripts and assets as a consistent version, and define rollback behavior. A readable cache does not establish that business data is current.
Accept recovery using fault actions and timestamps
On the actual controller and display resolution, separately block the business API, stop source updates, expire a session, close the browser and restart the device. Record the start of the fault, stale-data indication, reconnection, arrival of valid data and return of usable controls. Compare those times with server records.
Restore several terminals together and look for concentrated requests, duplicate alarms or repeated flashing. Release an update during a presentation cycle and verify all resources load. Agree test duration, acceptable data age and intervention conditions for the site's use. Handover documents should identify which faults recover automatically, which require a person and where maintenance staff can find the failure reason.