“Optimizing connection” is a bring-up state. The kit is powered, the local network may already exist, and the dish is still acquiring or settling the satellite path. Waiting can be normal. Staying there through a meal, or cycling forever, is not.
This guide explains when to leave the status alone and when to check obstructions, placement, power, cables and a controlled reboot. Start with the kit in front of you and the exact message shown in its app.
What the state is for
After a cold start, a power blink, a move, a cable reseat, or some software updates, Starlink has work to do before the WAN is useful. The dish must see sky, lock a path, and hand a usable network to the router. The app summarizes that work as optimizing—or a close synonym on some firmware.
During that window you may see:
- Starlink Wi-Fi already available, so phones “connect” with no internet,
- a progress or status line that does not yet say the service is ready,
- a dish that is physically moving on hardware that still tilts to search.
That is bring-up, not browsing. Treat it like a boot, not like a speed-test failure.
Optimizing is the wrong article if the kit was already online for hours and then dropped. Use Starlink keeps disconnecting. It is also the wrong article if Wi-Fi itself will not join. Use how to connect and connected without internet for join versus WAN isolation. Come back here when the app is explicitly stuck on optimizing.
When waiting is the right move
Give a cold kit time. A dish that just received power, especially after transport or a long off period, can sit in optimizing while it searches. Minutes can be normal. Hovering over the app and pulling power every thirty seconds is how you extend the state.
Waiting is reasonable when:
- You just plugged the kit in, moved it, or recovered from a power blink.
- The dish has a wide view of sky and is not under a roof.
- The app is making slow progress rather than looping the same error.
- Only one device is impatient; you have not confirmed a second device either.
Use the wait as observation, not as a void. Note the time you applied power. Note whether the dish has a clear horizon. Note whether Wi-Fi appeared. Those notes decide the next step if the status is still there later.
Do not invent a duration SLA. Hardware, sky, and how recently the kit moved all change the boot. If it cleared yesterday in three minutes and today has taken twenty in a blizzard with the dish half-covered, you are not looking at the same job.
When the wait has expired
Switch from patience to checks when any of these are true:
- Optimizing continues far beyond a normal boot, with no change in the app.
- The status appears, vanishes, and returns in a loop.
- You already waited through a full boot once today and it never became usable.
- The dish is indoors, under cover, or staring at a wall.
- Other devices on Ethernet see the same dead WAN.
At that point, more waiting is not a strategy. Local physical causes outrank internet folklore.
Obstructions and placement before another reboot
A dish that cannot see sky will optimize for a long time because there is nothing to finish. This is the most common “stuck” that is not a defect.
Look at the actual view:
- Trees, eaves, chimneys, masts, hillside, and neighboring structures.
- A “temporary” indoor windowsill. Glass and a roof overhang are not a sky view.
- A portable kit set on the ground beside a vehicle. The vehicle is an obstruction.
- Snow cap, heavy ice, or a cover you added that the radio did not ask for.
If you can move the kit safely, a test in the most open nearby patch of sky answers the placement question in one attempt. If that test leaves optimizing quickly and the old spot does not, you found the domain. Permanent mounting is a different project; do not turn this page into a roof guide.
Then read the app’s obstruction tools. How to read the Starlink obstruction map is the page for false warnings versus a real wedge of trees. A dirty map plus a stuck optimizer is a consistent story. A perfectly open map plus a stuck optimizer points at power, cable, or a kit that is not actually booting.
Power, cable, reboot—in that order
Power. Optimizing that never ends can be a kit that is starving or cycling. Confirm the outlet, the brick, and any extension. After wind, check that the outdoor side still has a dry, seated connector.
Cable. A dish on a nicked cable can sit in search forever. Reseat both ends with power off. Substitute a known-good official cable if you have one. Home-crimped replacements are a frequent source of mystery bring-up.
Reboot. One controlled power cycle is a fair test after placement and cable. Unplug, wait, restore, and leave it. A second reboot is reasonable if the first produced a different error. A tenth reboot is not a method.
After it leaves optimizing, confirm on a real page, then run a speed test from a device next to the router. You are checking that bring-up finished, not hunting a plan speed. If it never leaves the state, Ethernet will not magically complete alignment; it will only prove the WAN is still absent.
If optimizing clears and then the path dies on a timer, you have a disconnect pattern. If it clears into “connected” Wi-Fi with dead pages, you have the no-internet checklist. Keep the tickets separate or you will “fix” the wrong layer.
What “done” looks like—and what it does not
The status has finished its job when the app no longer sits on optimizing, a second device can load an uncached page, and the dish is not hunting as if it were still searching for sky. That is the only success test that matters. A prettier Wi-Fi icon on one phone is not success.
Firmware updates can extend a boot. If the app says the kit is updating, wait for that pass to finish before you pull power. Interrupting an update can strand you in a longer optimizing loop than the one you were trying to escape. Account and service holds belong after the radio path is physically possible. An unpaid or paused service can look like a kit that never becomes useful, but it does not explain a dish under a porch.
Heavy rain or a snow cap can stretch bring-up. That is still a local surface and sky problem. It is not a reason to announce a network-wide event. Clear what the official product allows you to clear, then give the kit another uninterrupted boot.
When optimizing finally clears, the primary next step is to run a Starlink speed test from a device next to the router—or on Ethernet if you have it. You are proving the WAN path, not collecting a trophy download. If the test cannot start, you never left the no-internet case.
Next steps that stay honest
When local checks are clean and the kit still never leaves optimizing:
- Try the clear-sky test if you have not.
- Inspect for physical damage after hail, a fall, or a yanked cable.
- Use the official Starlink support path for hardware that will not acquire in an open sky. That is their product.
- Do not paste a social screenshot as proof of a global event. Your dish under a deck is not a network outage.
After the kit is online, use the Connection Outlook to plan around a future weather window. How TNET works explains the public evidence approach; the Starlink app and support remain the tools for the current hardware state.
Leave the kit on a real sky view, give a cold boot a real wait, then change one physical thing. That order fixes more stuck optimizers than any status rumor. When the banner is gone, measure.