Communications Failure During Passage Runbook

A communications failure during passage should not be handled as a generic internet outage. The first question is whether the failure affects statutory distress and safety communications, operational coordination, owner or management communications, guest service, or only convenience connectivity.

Guest internet can fail without creating a safety communications failure. GMDSS, VHF DSC, MF/HF, EPIRB, SART, NAVTEX, EGC, AIS, LRIT, SSAS, and required radio watches are different. The runbook must keep those boundaries clear.

When communications degrade, classify the problem immediately:

• Distress and safety communications affected: Treat as a high-consequence operational issue and follow the vessel's radio, GMDSS, flag, and SMS procedures.
• Bridge or passage communications affected: Escalate to the master and bridge team; assess voyage plan and available alternatives.
• Management or owner communications affected: Preserve safety systems first, then restore business communications.
• Guest internet affected: Communicate limitations, protect operational bandwidth, and avoid risky changes during passage.
• Single bearer affected: Move traffic through the planned failover path and record the event.

1. Confirm vessel safety state: position, traffic, weather, navigation status, and whether any emergency exists.
2. Check statutory radio: VHF, DSC controller, MF/HF if fitted, satellite GMDSS equipment if fitted, NAVTEX or EGC reception, reserve power, and radio logs.
3. Check primary and backup broadband: LEO, VSAT, cellular, marina Wi-Fi if relevant, and shore VPN.
4. Check power and rack state: UPS, breakers, PoE switches, router/firewall, antenna controllers, and terminal status.
5. Check known external causes: coverage, obstruction, heading, weather, provider outage, roaming limit, account lockout, or data cap.

• Master: Any loss affecting safety communications, passage management, weather reception, emergency readiness, or reporting duties.
• OOW: Any bridge communications impact or navigational data dependency.
• ETO or AVIT: Any WAN, router, firewall, antenna, or monitoring issue.
• SatCom or IT provider: Any service, account, beam, plan, terminal, or routing issue outside onboard control.
• Yacht manager or DPA: Any extended outage, contractual impact, safety concern, or inability to meet planned communications requirements.

• Do not rewire WAN paths casually.
• Do not bypass the firewall to restore guest internet.
• Do not move management access onto bridge, GMDSS, or OT networks.
• Do not reset unknown equipment without recording current state.
• Do not tell guests broadband is a safety system.
• Do not assume a commercial satellite link replaces statutory radio duties.

• Time, position, route phase, weather, and vessel heading.
• Affected systems and unaffected systems.
• Radio checks performed and results.
• WAN link state, latency, packet loss, provider status, and terminal alerts.
• Changes made, who approved them, and rollback steps.
• Support case numbers and management notifications.

After restoration, the yacht should review whether the failure was equipment, coverage, account, installation, power, routing, or procedure. Update the communications matrix, support contacts, failover policy, and crew briefing if the failure revealed a weak assumption.