El Faro Weather Data Lesson: When Connectivity Becomes Operational

This article applies where a yacht depends on ship-shore connectivity for operational information, including weather, routing, management contact, telemedical advice, remote technical support, cyber monitoring, chart updates, owner office work, guest internet, or vendor escalation.

Applicability depends on the vessel's communications fit, operating area, GMDSS equipment, flag requirements, SatCom providers, LEO/VSAT/cellular architecture, bridge procedures, and whether the outage affects safety communications or only guest service.

Do not investigate a communications failure only as "internet down." Investigate what the failure stopped the yacht from knowing, deciding, or doing.

Separate four layers:

• The communications link: LEO, VSAT, FleetBroadband, cellular, marina Wi-Fi, radio, or GMDSS.
• The service riding on that link: email, weather, routing, monitoring, cloud dashboard, remote support, or guest traffic.
• The person or station that receives the information: bridge, captain, ETO, engineer, purser, management company, or vendor.
• The operational decision affected by the information.

A guest streaming outage and a delayed weather file may both appear as connectivity issues. They are not equivalent.

El Faro was a US-flagged cargo vessel that departed Jacksonville, Florida, for San Juan, Puerto Rico, on 29 September 2015. Hurricane Joaquin was developing in the Atlantic. On the morning of 1 October, El Faro sank near the Bahamas with the loss of all 33 people onboard.

The NTSB investigation covered many factors. This article focuses on one lesson: weather information was available through multiple channels, but the way it was delivered, accessed, interpreted, and acted on became part of the operational risk picture.

This was not a yacht incident. It was not a Starlink outage, a VSAT fault, or a guest Wi-Fi complaint. The relevance for yachts is sharper than that: modern vessels can have expensive communications equipment and still fail to get the right operational information to the right decision-maker at the right time.

El Faro sailed on a regular service route between Jacksonville and Puerto Rico. During the accident voyage, Hurricane Joaquin intensified and moved in a way that placed the vessel in increasingly dangerous conditions.

Weather information was available onboard through several sources. These included Inmarsat-C SafetyNET messages and Applied Weather Technology's Bon Voyage System, usually referred to as BVS. BVS was a weather-routing and voyage-optimisation application that could receive compressed weather files by email or broadband.

On El Faro, BVS weather files were delivered to the captain's email address. They were not sent directly to the bridge email address. To use the files on the bridge, the captain had to access his email, download the file, and forward it internally so it could be opened on the bridge computer.

That workflow matters. It meant the bridge did not automatically receive the same weather package at the same moment as the captain's account.

The NTSB report identified another issue. The regular BVS weather files carried hurricane-track information that could lag behind the latest National Hurricane Center information. Tropical update files were available, but El Faro had not elected to receive them. The report also identified a BVS update problem on 30 September: one weather file duplicated a file sent six hours earlier, making some information significantly older than expected.

On the evening before the sinking, a BVS weather file was emailed to El Faro at 2302. It was not downloaded until 0445 the next morning. By the time the captain reviewed it, the information was already old. The NTSB also noted that more current tropical cyclone information was available through Inmarsat-C SafetyNET and other onboard options.

At about 0503 on 1 October, the voyage data recorder captured the captain commenting that there were conflicting reports about the storm's centre.

That sentence is the operational lesson.

The problem was not simply whether the vessel had communications equipment. The problem was how weather data moved from source to ship, from ship account to bridge, from display to interpretation, and from interpretation to route decision.

There was no single "satellite failure" that explains El Faro.

The communications and information-flow issues were more subtle:

• The bridge did not receive BVS weather files directly.
• The captain's workflow created a human-dependent transfer step.
• The standard BVS files could contain hurricane information that lagged the latest advisories.
• A BVS update problem produced a duplicate file during the voyage.
• More current information existed, but it had to be recognised, compared, and given weight.
• Bridge resource management did not overcome the decision-making problem.

For yacht teams, that is the key distinction. The failure mode was not just technical. It was a system-of-use problem.

A yacht can have multiple domes, a LEO terminal, 5G backup, FleetBroadband, GMDSS, a firewall dashboard, and a weather-routing subscription. That still does not prove the bridge receives the operational information it needs when conditions deteriorate.

Yacht connectivity is often sold and judged through guest experience. The language is usually bandwidth, streaming, video calls, latency, and coverage.

Those things matter. They affect owner satisfaction and charter delivery. But the same communications architecture may also support:

• Weather and routing updates.
• Telemedical contact.
• Management and DPA escalation.
• Remote troubleshooting for AV/IT, PMS, VMS, batteries, engines, or bridge systems.
• Cyber monitoring and incident response.
• Crew welfare communication during demanding operations.

If the yacht treats all traffic as one general internet service, it may not notice when a convenience problem has become an operational problem.

The first investigation question should therefore be:

What was the yacht unable to receive, send, verify, or escalate during the outage?

For a yacht incident or near miss, test this pattern.

Technical path:

• One or more WAN services degrade.
• Failover works only partly, or not at all.
• Operational traffic competes with guest traffic.
• Weather, email, cloud dashboards, or remote support are delayed.
• Logs are too weak to prove which link carried which service.

Information path:

• The bridge assumes the latest information has arrived.
• The captain or officer relies on a single product without cross-checking.
• A file, email, app, or dashboard is not visible at the station where the decision is made.
• A purser, ETO, or shore contact knows about a connectivity problem before the bridge does.

Management path:

• The itinerary assumes seamless coverage.
• The owner or charter plan pushes the vessel toward remote service expectations.
• The yacht has no written low-bandwidth operating mode.
• Provider support is reactive because no one owns escalation.

El Faro should not be reduced to a connectivity story. But it does show that information flow belongs inside voyage safety, not outside it.

Build three timelines.

First, build the link timeline.

• Which WAN links were available?
• Which link was primary at departure?
• When did the first degradation occur?
• Did failover happen automatically?
• Was failover visible to the bridge or only to the technical team?
• Were there provider alerts, terminal faults, obstructions, rain fade, SIM problems, DNS issues, firewall problems, or account restrictions?

Second, build the information timeline.

• Which weather, routing, management, or support information was expected?
• When was it sent?
• When was it received?
• Who could see it?
• Was it forwarded manually?
• Was a newer version available elsewhere?
• Did anyone compare sources?

Third, build the decision timeline.

• What operational decision depended on the information?
• Who made the decision?
• What alternatives were considered?
• Was degraded communications discussed in the bridge log, passage plan, or master's review?
• Did the yacht continue because the risk was understood, or because the information gap was invisible?

This structure prevents the investigation from becoming a complaint about Wi-Fi speed.

Preserve evidence before provider portals, firewall dashboards, and cloud logs roll over.

Minimum evidence:

• Firewall WAN logs and interface history.
• SD-WAN or bonding-router event logs.
• LEO, VSAT, FleetBroadband, cellular, and marina Wi-Fi terminal status.
• Weather and routing email headers.
• Provider outage notices and support tickets.
• Bandwidth, latency, packet-loss, and failover graphs.
• DNS and captive-portal logs if users reported "internet down."
• Bridge log entries and passage-plan notes.
• Screenshots of weather products actually used onboard.
• Internal messages showing who knew about the outage and when.

Also preserve the human evidence. Ask the bridge team what they thought they had received, what they trusted, and what they believed was current.

Mitigation starts by separating operational communications from guest internet.

Define protected operational services.

• Weather and routing products.
• Captain and bridge email.
• Management and DPA contact.
• Telemedical contact.
• Remote support for critical systems.
• Cyber monitoring and alerting.

Then define how those services behave when bandwidth is poor.

• Which services get priority?
• Which guest services are throttled or paused?
• Which link is preferred for operational traffic?
• Which link is kept as a low-bandwidth reserve?
• Who receives alerts when failover occurs?
• Who tells the captain that operational connectivity is degraded?

Finally, test the process.

• Simulate loss of the primary WAN.
• Confirm weather and email still work.
• Confirm provider escalation contacts are current.
• Confirm the bridge can see which information is current.
• Confirm the purser knows what to tell guests without hiding operational risk.

Consider a yacht on a remote charter itinerary. Guests are streaming heavily, the owner is using video calls, and weather routing is being updated for a night passage.

The LEO service becomes obstructed by heading and sea state. VSAT is degraded by weather. Cellular is unavailable. The firewall keeps guest traffic alive, but the weather email queue is delayed and the bridge assumes the latest routing update has arrived.

The technical fault may be small. The operational consequence may not be.

The yacht needs a procedure that makes the status visible:

• Bridge notified when operational links degrade.
• Guest traffic reduced before operational traffic fails.
• Weather products checked by timestamp and source.
• Alternate communications tested before the yacht is committed.
• Management briefed in plain language.

This is where connectivity becomes command support.

After a communications incident, closeout should not stop at "provider outage."

Useful closeout should include:

• Root cause or best-supported explanation.
• Link and failover evidence.
• List of operational services affected.
• Any decisions delayed or made with stale information.
• Updated traffic-priority policy.
• Updated provider escalation contacts.
• Low-bandwidth operating procedure.
• Bridge familiarisation on weather-product timestamps.
• Test evidence showing failover works as intended.

If the outage exposed unrealistic guest expectations, record that too. It is a management risk, not an ETO problem.