Starlink's New Satellites and Your SD-WAN Backup Plan

Most mid-sized sites run on one primary internet circuit, often fiber or cable, with a cellular modem or a second wired circuit as backup. On paper that is redundant. In practice, the two circuits often share more than anyone realizes: the same street, the same conduit into the building, sometimes the same upstream carrier. When a backhoe cuts the line, both can go down together.

That is why low-earth-orbit satellite service has become a common third path in SD-WAN designs. It reaches the site through the sky, not the street. A recent launch is a good prompt to revisit how it fits.

What changed on September 28

On September 28, 2026, SpaceX’s Starship reached orbit for the first time and deployed 26 of its new “V3” Starlink satellites, as Light Reading reported. According to that report:

• Each V3 satellite supports about 1 Tbit/s of downlink and 160 Gbit/s of uplink capacity, which the article describes as roughly 10 times the downlink and 22 times the uplink of a V2 satellite.
• SpaceX said a fully loaded Starship can carry up to 60 V3 satellites.
• SpaceX expected the satellites to start serving customers “within a few weeks”, without giving a date.

It was also a test flight. The ship had an engine failure during ascent, and the mission was cut short after about three hours instead of ten. As of October 8, 2026, we have not seen a date for when V3 capacity will be broadly available or how quickly more launches will follow.

The honest reading: this is the start of a capacity increase, not a finished one. Uplink is the number worth watching. Many business uses, such as video calls, cloud backups and file uploads, push data up, and that has historically been satellite’s weaker direction.

What more capacity does not change

Extra satellites do not change the basics of how a satellite link behaves at your site:

• It needs a clear view of the sky. Trees, nearby buildings and rooftop equipment can block the dish for part of each hour.
• Weather and conditions vary. Performance can change with heavy weather and with how many other users share the same coverage area.
• Latency moves around. Low-orbit latency is much lower than older geostationary service, but it shifts as satellites pass overhead. Your SD-WAN health checks will see that.
• Addressing may differ from your wired circuits. A satellite connection may sit behind carrier-grade NAT, with no public address of your own, depending on the plan. Confirm what yours provides.

None of these are reasons to avoid satellite. They are reasons to design for them.

Designing satellite into the SD-WAN

1. Decide its role. Standby only (used when the primary fails), or active (carrying some traffic every day)? Active use keeps the link exercised and proves it works, but costs more data. Standby is cheaper but tends to fail silently until the day you need it.

2. Write steering rules by application, not by link. Most SD-WAN platforms can measure latency, jitter and loss on each path and move traffic accordingly. Decide in advance where voice, video meetings, ERP sessions, backups and guest Wi-Fi go when the primary is healthy, when it is degraded and when it is down. Bulk transfers are good candidates to move to satellite, or to pause, during an outage.

3. Test real-time traffic over satellite on purpose. Do not assume voice and video will be fine. Force a test call and a video meeting over the satellite path during business hours and listen for problems. Adjust jitter buffers or steering thresholds based on what you find.

4. Check addressing against everything that depends on it. SD-WAN overlays usually build their tunnels outbound, so they often work behind carrier-grade NAT. The problems show up elsewhere: firewall allowlists at SaaS vendors or partners that expect your fixed public address, inbound remote access, and site-to-site VPNs outside the SD-WAN. List every place your public IP address is configured, and decide what happens to each during failover.

5. Tune failover so it does not flap. If health-check thresholds are too tight, normal satellite latency swings can trigger needless path changes. Measure a week of baseline latency, jitter and loss on the satellite link before setting thresholds.

6. Power it like the primary. A backup that loses power in the same outage is not a backup. Put the dish’s power supply, the SD-WAN edge and the switch it connects to on the same UPS, and check the runtime.

7. Treat the install as a building project. Roof penetrations, mounting, cable runs, lightning protection and landlord approval all take time. Get a site survey, including an obstruction check, before you order.

8. Monitor it every day. Alert on the satellite path going down even when the primary is fine. Track data usage against your plan’s limits so a long outage does not end in throttling.

The contract side

Satellite plans for business change often. Before committing, get in writing which plan you are on, what it costs per month and per terminal, whether there is a term commitment, what data is included, what happens when you exceed it, and what support you get when the service is down. Compare that with the cost of a second wired circuit from a different carrier on a genuinely different physical route, which is sometimes available and sometimes not.

Questions to ask this quarter

• Do our primary and backup circuits share any physical path, building entrance or upstream carrier?
• Which applications must keep working during an outage, and have we tested each over the backup path?
• Does our satellite plan give us a public IP address, and what breaks if our address changes during failover?
• Are the dish, router and SD-WAN edge on UPS power, and for how long?
• Who gets alerted when the backup path fails while the primary is still up?
• What does the plan cost in total, what are its data limits, and what support does it include?

If you want an independent look at your circuits and whether your backup paths are truly diverse, our free telecom and circuit assessment is a good place to start.