Connectivity Monitoring Dashboard Minimum Set

A yacht connectivity dashboard should answer a practical question fast: what is working, what has failed, what changed, and what evidence do we have?

The dashboard does not need to look like a shore-side network operations centre. It needs to help the ETO, AVIT engineer, captain, IT provider, SatCom provider, and management company stop guessing during a guest trip, owner office call, marina arrival, or passage.

The best setup usually has two views:

• Firewall view: What the yacht is doing with WAN links, routes, SD-WAN health, VPNs, firewall policies, and failover.
• Monitoring view: What independent checks show from the outside of each device or service, including ping, interface traffic, uptime, alerts, and historic trend data.

FortiGate and PRTG are useful examples because they show the difference. A FortiGate can make routing and SD-WAN decisions. PRTG can watch devices and services as sensors and keep alert history. They should agree on the story, but they are not the same tool.

At a minimum, monitor:

• WAN state: LEO, VSAT, cellular, marina Wi-Fi, shore fibre, and any backup path.
• Active route: Which link is currently carrying guest, owner office, crew, vendor, and management traffic.
• Latency: Current and trend values to at least two reliable targets per WAN link.
• Jitter: Especially for video calls, voice, remote desktop, and VPN sessions.
• Packet loss: Current and trend values per WAN link.
• Throughput: Practical traffic levels, not just theoretical service speed.
• Data usage: Priority data, cellular cap, fair-use thresholds, and expected throttle points.
• Firewall state: SD-WAN health, VPN state, tunnel health, policy hits, and failover decisions.
• DNS state: Resolver availability and whether traffic is using the expected resolver.
• Terminal state: Antenna online, obstruction, alignment, modem state, or provider alert.
• Network device state: Firewall, core switch, access switches, wireless controller, APs, and rack UPS.
• Alert history: Time of change, duration, link affected, who acknowledged it, and what was changed.

On a yacht using FortiGate or a similar firewall, the dashboard should not only show that an interface is up. It should show whether each WAN link is healthy enough to carry the traffic assigned to it.

In FortiGate SD-WAN, Performance SLA and link health monitoring can be used to test WAN members against targets and judge link quality using metrics such as latency, jitter, and packet loss. Fortinet documentation also explains that failed health checks can remove routes for a broken link so traffic uses other links instead.

For a yacht, that means the FortiGate view should show:

• WAN member names that match the real installation, such as Starlink, VSAT, 5G, Marina Wi-Fi, and Shore Fibre.
• Performance SLA targets for each link, not only a single generic internet target.
• Latency, jitter, and packet-loss values per link.
• Which link is passing or failing the SLA.
• Which link is currently preferred for guest, owner office, crew, monitoring, and vendor support traffic.
• VPN tunnel status for shore office, management company, or approved vendor access.
• Logs showing when a link failed, when it recovered, and whether routing changed.

Yacht Example

A yacht has Starlink as the primary guest and owner-office link, VSAT as contracted satellite backup, and 5G as a coastal backup. During an owner video call, guests report buffering.

The FortiGate dashboard shows:

• Starlink is still up, but packet loss is above the yacht's accepted threshold.
• SD-WAN has not moved owner-office VPN traffic because the rule only tests interface up/down.
• 5G is healthy, but guest streaming has priority over owner-office VPN.

The fix is not just rebooting Starlink. The useful action is to adjust the SD-WAN health and traffic rules so owner-office traffic fails over when the service is degraded, not only when the terminal is fully down.

PRTG or a similar monitoring tool should give the second view: device and service state over time. It should not replace the firewall, but it can catch issues the firewall does not present clearly to crew or management.

PRTG is built around probes, devices, and sensors. For yacht connectivity, useful sensors might include:

• Ping sensors for firewall WAN gateways, Starlink router or terminal path, VSAT modem, 5G router, and important public test targets.
• SNMP Traffic sensors for firewall WAN interfaces, core switch uplinks, access switch uplinks, and high-use AP or controller ports.
• HTTP or HTTPS sensors for cloud dashboards, owner-office services, captive portals where appropriate, and approved management portals.
• Device health sensors where supported for firewall CPU, memory, disk, temperature, UPS state, and switch status.
• Notification triggers for sensors changing to warning or down states.

Yacht Example

The FortiGate says traffic moved from Starlink to 5G, but guests still report poor service.

PRTG shows:

• The 5G router is reachable, but the SNMP Traffic sensor shows the interface is saturated.
• Ping latency to the firewall is normal, but ping latency to public targets is high.
• The core switch uplink is clean, so the problem is not the onboard LAN.
• A notification shows the 5G data cap threshold was reached earlier in the day.

This changes the response. The ETO does not need to chase Wi-Fi APs or reboot switches. The issue is WAN capacity and plan management.

The firewall and monitoring dashboard should answer different parts of the same incident:

• Firewall: Which path did traffic take, and why?
• Monitoring: Which device or service changed state, and when?
• Provider portal: Was there an account, data, beam, obstruction, or service-plan issue?
• Logs: Who changed policy, rebooted equipment, approved vendor access, or acknowledged an alert?
• Crew evidence: What did users experience, and which services were affected?

If those views do not line up, the dashboard is not yet good enough. A yacht should not need three vendors on a call just to decide whether the fault is Starlink, VSAT, 5G, firewall policy, DNS, Wi-Fi, or the owner's laptop.

Guest dashboards should never expose operational details, admin panels, public IPs, support links, bridge data, radio systems, CCTV, or OT. If a guest-facing status page is used, it should be simple: internet status, degraded service, or temporarily unavailable.

Crew and technical dashboards can show more detail, but access still needs control. Use named accounts, MFA where available, and role-based access. A steward should not need firewall admin access to tell a guest that internet is degraded. A captain should be able to see business impact without having to interpret every SNMP channel.

Use fewer, better alerts:

• All WAN links down.
• Primary WAN degraded for more than the accepted threshold.
• SD-WAN failover occurred.
• Failover succeeded but high-priority traffic did not recover.
• Owner-office VPN down during an approved working window.
• Vendor remote support tunnel active outside an approved support window.
• Cellular data cap or priority-data threshold reached.
• Antenna obstruction, modem offline, or terminal portal alert.
• Firewall, core switch, or monitoring probe stopped sending logs.

Avoid alerting everyone for every minor latency spike. A dashboard that creates alert fatigue will be ignored when the real failure arrives.

For every meaningful outage, capture:

• Start time, end time, position, route phase, and vessel activity.
• Active WAN before, during, and after failover.
• Firewall SD-WAN state and relevant logs.
• PRTG or monitoring graphs for affected sensors.
• Latency, jitter, packet loss, DNS state, and interface traffic.
• Provider portal alert, service case, or terminal error.
• Any account, plan, or data-cap change.
• Any manual change made by crew, provider, or vendor.
• Screenshots or exported reports where practical.

Before accepting a monitoring dashboard, test it by creating controlled failures:

1. Disconnect each WAN link in turn.
2. Confirm the firewall marks the link failed or degraded.
3. Confirm traffic moves according to policy.
4. Confirm PRTG or the monitoring tool sees the device, interface, or service state change.
5. Confirm alerts reach the correct people and no unnecessary people.
6. Confirm logs show who changed configuration.
7. Confirm a report can be exported for management or support.