A Starlink session that “keeps disconnecting” is usually one of three different failures: a brief satellite-path gap, a local Wi-Fi drop, or a WAN loss while the home network still looks connected. Treat those as separate problems. Guessing at a reboot, a new cable, and a dish move in the same afternoon hides the cause.
The useful method is simple: classify the symptom, keep a short log, change one thing, then test.
Start by naming the drop
People use “disconnect” for anything from a one-second hitch in a call to a router that will not come back. Those events do not share a cause. Before you move hardware, decide which of these you actually saw.
Brief drops last a second or a few seconds. Video stutters, a game rubber-bands, a page hangs, then the session recovers without you tapping Wi-Fi. The Starlink app may show a short outage, an obstruction mark, or nothing obvious if you open it later. Ethernet users feel these too. That points at the satellite path, not the living-room radio.
Wi-Fi drops take one device—or every wireless device—off the local network. The phone shows no Starlink SSID, or it shows the SSID and cannot join. A laptop on Ethernet may still browse. A second phone in the same room may stay online. That is a coverage, congestion, roaming, or router-radio problem until proven otherwise.
WAN loss keeps Wi-Fi up. Devices stay associated, DHCP still works, and the captive feeling is “connected, no internet.” Browsers fail, calls drop, but the local network looks healthy. That pattern belongs with Starlink connected without internet more than with a new access point.
If you cannot tell which class you hit, you are not ready to replace parts. The log below exists to make the class visible.
Keep a symptom log for a few events
You do not need a lab notebook. You need enough structure that the fifth drop can be compared with the first. For each event, write:
- Clock time and duration. “A few times this afternoon” is not a pattern. “12–20 seconds at 7:14 p.m. and 7:31 p.m.” is.
- Which devices failed. One phone, every Wi-Fi client, or Ethernet as well.
- What the app showed during the event, if you can open it quickly: dish state, obstruction, offline, or a generic outage.
- Sky and weather. Clear, rain, snow on the dish, wind, nearby trees moving.
- What else was running. Large downloads, a console update, a camera backup, a mesh backhaul under load.
- What you had already changed that day: reboot, cable reseat, snow clear, new Wi-Fi channel.
Three to five logged events beat a week of mixed memory. Recurring drops at the same compass bearing, the same hour, or only on wireless clients already narrow the list.
Confirm the path with one wired check
If you have Ethernet on the Starlink router—or a LAN port on a bypassed third-party router—put one laptop on that cable for the next drop. Leave a phone on Wi-Fi.
- Wired client dies and the phone dies: the WAN or the dish path is in play.
- Wired client lives and the phone dies: stop blaming the sky. Work the Wi-Fi.
- Both live, but one app fails: that app, VPN, or device is the outlier.
This single split prevents the most expensive mistake in this cluster: buying a new dish because a phone on the far side of the house roams badly.
Obstructions: repeating gaps with a direction
Trees, roof ridges, chimneys, vehicles, and neighboring buildings take bites out of the sky. A narrow obstruction can look healthy at noon and fail at 7 p.m., when the useful sky sweeps through that sector.
Clues that obstruction is the cause:
- Drops cluster rather than appearing as a total outage.
- The Starlink app’s obstruction view marks the same sector across scans.
- Moving a few feet, or raising the mount, changes the pattern.
- Ethernet and Wi-Fi fail together for a few seconds, then recover.
Run a fresh scan and read it as a map, not a pass/fail badge. Direction and repeatability matter more than a single red smear. The full method, including “it says obstructed but the sky looks open,” is in How to read the Starlink obstruction map. Do not prune from a one-off scan taken while a van sat in the driveway.
Placement fixes are ordinary: more sky, less foliage, a stiffer mount. If wind nods the pole, that is also a mount problem—see what to look for in a high-wind mount.
Power: brownouts that look like network faults
A dish that reboots when a well pump starts, a router that dies on a hot extension reel, or an inverter that clips under surge will look like random disconnects.
Check, in this order:
- Wall power first. Use the official supply in a known-good outlet, not a strip shared with a heater.
- Both ends of the dish cable. Reseat fully. Look for bent pins, crushed boots, and water in the housing.
- Aftermarket adapters and extra junctions. If drops started after a new cable or splitter, reverse that change before you chase satellites.
- Off-grid and generator feeds. Voltage sag causes cyclic reboots. Diagnose on a stable source if you can; size later with the off-grid power sizer.
A reboot that coincides with other appliances is power until proven otherwise. Do not invent a wattage budget from a forum post—verify current figures for your hardware.
Cables: intermittent physical faults
Pinch points at eaves, UV-cracked jackets, wind-sensitive connectors, and indoor kinks produce drops that no setting will fix. Walk the run. If a wired session dies when you flex a section, stop troubleshooting the sky. Use a cable meant for that kit. Follow current Starlink instructions for your generation when disconnecting; forcing a connector turns a drop into an outage.
A cable that fails only in rain is a seal problem, not rain fade. Use the weather guides below so you do not mix the two.
Weather: real path stress versus coincidence
Heavy rain, wet snow on the dish, ice, and some storm structures can degrade a satellite path. Ordinary overcast usually does not. The mistake is to blame “the weather” for every evening drop because it rained once last Tuesday.
Use weather as a hypothesis only when the log lines up:
- Drops during rain or a storm, recovering when the cell passes.
- Snow sitting on the dish, improved after a safe clear or Snow Melt—see Starlink Snow Melt.
- Heat-soak or freeze affecting power supplies and cables more than the radio—see extreme heat and cold.
The wider picture is in Does Starlink work in bad weather?. Use the Connection Outlook when you need to compare a future weather window with a likely hardware fault.
Load: the network is up, the path is crowded
A household can knock a video call over without a true disconnect. Uploads, cloud backups, console patches, and a pile of streaming clients raise latency and loss until apps give up and look “disconnected.”
Clues:
- Drops at the same family-usage hour.
- Speed tests look fine at 6 a.m. and ugly at 8 p.m.
- Ethernet still shows a session, but calls fail when someone starts a large upload.
That is congestion or Wi-Fi airtime, not a dying dish. Pause the heavy job and see whether the “disconnects” stop. For how many clients you can actually share, use How many devices can connect to Starlink?—there is no universal headcount. For the speed and loss picture, read why Starlink is slow and elevated packet loss.
Change one thing, then test
The diagnostic rule is simple and easy to break: one change, one test.
Good sequence:
- Classify the last few events (brief / Wi-Fi / WAN).
- Wired-versus-wireless check during the next drop.
- If the WAN is dying: obstruction scan, then power, then cable, then weather alignment.
- If only Wi-Fi dies: stay local—channel, placement, mesh hop, client roaming. Do not move the dish yet.
- After each change, wait for the same conditions that used to fail, or reproduce them.
A reboot is a change. Two reboots plus a cable reseat plus a firmware wait is not a test. If the problem vanishes after a bundle of changes, you cannot name the cause, and it will return.
When you test, measure. Run the Starlink speed test on the same device and path (wired if you are chasing WAN) before and after the change. Look at download, upload, latency, and whether the run completed. One run is a snapshot; two or three in the failure window are a comparison. How to read speed test results explains a healthy-versus-suspicious set.
If brief drops remain after a clear sky, clean power, and a solid cable, you are in path-quality territory—how reliable Starlink is and Starlink latency—not “buy a new router tonight.”
Widespread outages exist, but they are the last explanation after you classify your own drop. TNET does not operate Starlink and does not see your terminal’s counters. If the app reports a service outage and every local symptom matches, wait and retest. If the app is healthy and only your site drops, stay on this checklist.
Most “keeps disconnecting” threads mix two layers. Separate them. The cause is usually ordinary: a tree sector, a tired connector, a phone that never had coverage, or a backup that saturates upload. Fix that layer. Leave the rest of the kit alone until the log says otherwise.
Primary next step: Run a Starlink speed test on the same path you are debugging—wired for WAN drops, wireless only when Wi-Fi is the suspect—and compare a quiet-hour run with a run in the failure window after each change.