Most vessels working out of Singapore now run a single flat-panel LEO terminal and treat it as infrastructure. It works until it does not, and the failure almost never happens at a convenient moment. This article covers how to design a satellite communications failover stack for a vessel operating in the Singapore Strait, the Malacca Strait and Indonesian and Malaysian waters, so that when the primary link drops the bridge still has email, ops still gets its reports, and the master can still make a phone call.

Why single-constellation vessels lose service

A LEO terminal is not a single point of failure in one way; it is a single point of failure in about seven ways. From what we see on vessels we support, the causes cluster as follows.

• Obstruction. A dome, mast, crane boom, derrick or a container stack sits in the antenna’s field of view. On tugs and OSVs the culprit is usually a temporary lift or a repositioned A-frame, so the fault appears months after a clean commissioning.
• Rain fade. Ku and Ka band are absorbed and scattered by heavy rain. A Sumatra squall or a genuine monsoon cell over the Strait can put a link into brownout for ten to forty minutes. This is not a fault, it is physics.
• Cell congestion. The waters off Singapore are one of the most densely trafficked patches of ocean on earth, and a very high proportion of the vessels in it now carry a terminal. At anchor off the Eastern Bunkering Anchorage on a Friday evening you are sharing capacity with a large number of neighbours.
• Terminal or cabling fault. Heat, humidity, salt and vibration are hard on connectors. A corroded PoE injector or a chafed cable run through a bulkhead gland is a common quiet killer.
• Power fault. The terminal is downstream of a converter, a breaker or a UPS that somebody switched during a generator changeover.
• Account and billing suspension. A card expires, a corporate account goes past due, or a plan is paused after a lay-up. The hardware is fine and the service is off.
• Regulatory and geographic blocks. Service authorisation is not uniform across the region and can change. We have written separately on the regulatory position for Starlink in Malaysian and Indonesian waters, and it is a real design input, not a footnote.

Redundancy, failover and bonding are three different things

These get used interchangeably in sales conversations and they should not be.

• Redundancy is having a second path available. It costs money and does nothing on its own.
• Failover is the automatic decision to move traffic from a failed path to a healthy one. This is the part most vessels get wrong.
• Bonding aggregates several paths into one logical link so a session survives the loss of any member. It is the strongest answer where you can afford it and where you have enough concurrent bandwidth to justify it. We covered that build in detail in our guide to a bonded Starlink and OneWeb SD-WAN setup, and this article is deliberately about the cheaper, more common case: one good link plus a disciplined fallback.

The tiered design

A workable stack for a Singapore-based vessel has three tiers, and each tier answers a different failure mode.

Tier 1, primary LEO. A flat-panel maritime terminal carrying essentially all traffic. High throughput, low latency, unmetered enough for crew use.

Tier 2, the mid-tier. This is either a second LEO service on a different constellation, or, for vessels that genuinely stay inside coastal range, a marine 4G/5G router with regional SIMs. In the Singapore Strait and along the Malacca coast, cellular is a strong second tier because coverage from Singapore, Johor and the Riau islands overlaps for a good part of a typical harbour-craft day. Our notes on extending mobile coverage offshore with a marine router set out realistic range expectations, and the honest number is much closer to 10–20 nautical miles with a decent external antenna than the figures printed on a box.

Tier 3, the L-band lifeline. This is the tier operators skip and then regret. Iridium’s Certus service is currently offered in three classes: Certus 100 for IoT and low-rate telemetry, Certus 200 for basic IP and voice, and Certus 700 as the fastest L-band tier, quoted at up to roughly 704 kbps down and 352 kbps up. An IsatPhone or a Certus 100/200 terminal will not stream anything, and that is precisely the point. L-band works through the rain cell that just took out your Ku link, uses very little power, and has a small omnidirectional antenna with no moving parts to seize up. If you are weighing the entry options, our comparison of Iridium GO, the 9555 handset and Certus 200 is the right starting point.

On cost, the useful framing is that the lifeline tier is cheap insurance against the primary tier. A low-usage L-band standby subscription sits indicatively in the S$60–200 range per month depending on class and committed data, quoted per vessel, while a second broadband path is a materially larger commitment. These figures are indicative only, they move with airtime terms and hardware bundles, and everything we supply is quoted per vessel against the actual fit.

Vessel type	Primary	Secondary	Lifeline	Our recommendation
Harbour craft, launches, pilot boats	LEO flat panel	Marine 4G/5G router, dual regional SIM	IsatPhone handset on the bridge	Cellular is the cost-effective second tier. Do not buy a second dish.
Tug and barge, coastal tow	LEO flat panel	Marine 4G/5G router	Iridium Certus 100 or 200	Certus 100 for position and towline telemetry that must never stop.
Fishing vessel, extended trips	LEO flat panel	None practical offshore	Certus 200, or IsatPhone plus a tracker	Skip the mid-tier and spend the money on a real L-band lifeline.
Yacht and charter	LEO flat panel	Second LEO service or 4G/5G near shore	Certus 200	Guest expectation drives a genuine second broadband path.
OSV, offshore support	LEO flat panel	Second LEO constellation	Certus 700	Charterer SLAs usually justify full dual-broadband plus L-band.

What must survive a failover, and what must not

When you drop from a 200 Mbps link to a 350 kbps one, you are not degrading gracefully unless you have decided in advance what dies. Write the priority list before you configure the router.

Priority	Traffic	On Tier 2	On Tier 3 (L-band)
1	Distress, duty-of-care and safety calls	Allow	Allow, always
2	Bridge and master email, text only	Allow	Allow, attachments stripped or queued
3	AIS/position, engine and tank telemetry	Allow	Allow, low-rate
4	Ops reporting, noon reports, port forms	Allow	Allow, compressed
5	ECDIS and chart updates	Allow, off-peak	Block, queue until restore
6	CCTV, remote support, cloud backup	Throttle	Block
7	Crew Wi-Fi, streaming, social, gaming	Throttle hard	Block entirely

Router-level mechanics that actually work

Health checks must detect brownouts, not just link-up. The single most common failover failure we see is a router that keeps traffic on a dead LEO link because the Ethernet port is still up and the terminal is still handing out a DHCP lease. Configure active health checks: a DNS or ICMP probe to two or three off-vessel targets, plus an HTTP check, with a latency and loss threshold, not merely reachability. A link at 90 per cent packet loss should fail the check.

Thresholds and hold-down timers. Squalls come and go. Set the failover trigger at something like three consecutive failed probes at five-second intervals, and then set a restore hold-down of two to five minutes so the vessel does not flap between paths every time the rain eases. Flapping is worse than a clean outage because sessions and VPNs never settle.

Per-VLAN policy. Crew Wi-Fi must be shed first, automatically, without anyone touching a keyboard. This is only possible if crew, guest and operations traffic are already separated, which is the argument for doing the crew, guest and ops VLAN design properly at fit-out. Bind each VLAN to an outbound policy: ops VLAN may use any WAN, crew VLAN may use WAN1 only.

DNS and VPN behaviour. Set explicit resolvers per WAN or the vessel will keep querying a resolver only reachable over the dead path. If you run a site-to-site VPN back to the office, terminate it on a SpeedFusion-style overlay or at least shorten the dead-peer-detection interval, otherwise the tunnel will sit stale for minutes after the underlying WAN has already moved.

Cap the expensive backup. A stuck failover onto metered L-band, undetected over a weekend, is how a vessel produces a five-figure bill. Apply a hard monthly data cap per WAN in the router, a daily sub-cap, and an alert to the superintendent by SMS or email the moment the vessel moves onto Tier 3. Configure the cap to block rather than throttle. Fleet-wide, this is much easier to police from a central portal, which is why we usually set this up alongside InControl 2 for fleet management.

Test it at the quay, not at sea

An untested failover design is a hypothesis. Before the vessel sails, run this at the berth with the superintendent present.

• Pull the primary terminal’s power. Time how long until traffic moves and note what breaks.
• Leave the terminal powered but block its outbound path at the router, simulating a service suspension or regional block. This catches health checks that only test link state.
• Throttle the primary WAN to simulate rain fade rather than a hard drop, and confirm the brownout threshold trips.
• Confirm crew Wi-Fi is actually shed and that the bridge PC still sends email.
• Restore the primary and confirm the hold-down timer works and the VPN re-establishes.
• Write down the times. Record them in the vessel’s comms procedure so the next crew knows what normal looks like.

Honest limitations

No design removes outages, it only shortens them and makes them survivable. Two LEO constellations can still both degrade in the same heavy monsoon cell, cellular disappears once you are properly offshore, and L-band gives you a lifeline rather than a working office. Failover also adds configuration that can itself fail, so a badly tuned design is worse than none. Most importantly, none of this is GMDSS. Commercial broadband, on any constellation, does not discharge your statutory distress and safety obligations, and your MPA-required GMDSS equipment and its testing regime remain entirely separate. Treat the two as parallel systems that never substitute for each other.

Get a redundancy design and quote for your fleet

We can design the failover tiers for your vessel type, supply and fit the terminals and router, and configure the health checks, VLAN policies and data caps so a failover is quiet rather than expensive. Sales at Envisiondata Pte Ltd — sales@envisiondatasg.com — or WhatsApp Steve directly on +65 9088 4899.

How we can help

The right connectivity depends on your vessels, routes and budget, not on a product brochure. We design, install and support set-ups that keep you online at a sensible monthly cost.

• Free review of your current connectivity and bills
• Starlink, OneWeb, VSAT and 4G/5G options compared for your route
• Automatic failover so crews stay online when a network drops
• Installation and 24/7 monitoring across Singapore and SE Asia

What happens when you contact us

1. Short call or meeting — we listen to how your vessels operate.
2. Vessel and route review — we check equipment, space, power, contracts and licensing.
3. Clear recommendation — a written proposal and SGD quote, with options.
4. Install and support — commissioning, testing and ongoing support.

Related: Dual-LEO Resilience bundle (Starlink + OneWeb)