Starlink Debug Data Guide: Read Every Field That Matters

The Starlink Statistics page is for owners who are past the buying stage and trying to explain a specific failure: a video call froze at 8:12 pm, a game rubber-banded even though download speed showed 140 Mbps, or the app says “online” while a VPN keeps reconnecting. Starlink is a low Earth orbit satellite internet constellation operated by SpaceX, and low Earth orbit is an orbital zone close enough to reduce round-trip delay compared with geostationary satellite service. The low Earth orbit trade-off is constant handoff: your dish has to track moving satellites, shift beams, and ride through weather, congestion, and firmware changes. Debug data is where those handoffs leave fingerprints.

Treat the fields as a sequence. First prove the dish has a clean view of the sky. Then prove the radio link is stable. Then separate Starlink network behavior from your router and WiFi. Only after those steps should you blame a plan tier, a crowded cell, or a beta firmware release. If you want a quick outside measurement while you read, run the SatSpeedCheck speed test on Ethernet and save the latency graph. If your issue began after mounting, compare the numbers against the Starlink installation guide and the obstruction guide before moving hardware.

“The first debug screen I trust is not download speed; it is the 12-hour story. A dish with 160 Mbps down and 4 percent obstruction will still drop real-time apps because a two-second handoff failure is more visible than a 50 Mbps speed loss.”— Hommer Zhao, SatSpeedCheck network analyst

Where to find the fields

In the Starlink app, open Statistics first. That page shows live latency, network outages, obstruction, speed, and router status in a readable view. Debug Data is the deeper dump behind it. On most app versions, it sits under Advanced or appears after tapping into diagnostics. The exact labels change between releases, but the diagnostic logic stays stable: Starlink exposes a dish section, a router section, an alerts section, a software section, and counters for ping, obstruction, and outages.

A ping is a small test packet used to measure round-trip time. Ping drift is the gap between your normal latency and a sustained spike, not a single outlier. Obstruction is the percentage of scheduled sky view blocked by trees, roofs, masts, terrain, or snow. Beta software is a firmware build released ahead of the broad stable channel, usually to test routing, radio, thermal, or router changes on a smaller install base.

SpaceX says in its own Starlink specifications that service performance depends on package, location, and network conditions, so do not read any single field in isolation. The same 70 Mbps result can be excellent in heavy rain, bad at 3 am, normal after priority data exhaustion, or irrelevant if the real complaint is 3 percent packet loss over WiFi.

The field-by-field decoder

Use this table as the first pass. It does not cover every internal counter Starlink may expose in every build, but it covers the fields that should change what you do next. The thresholds are intentionally practical: they answer whether to move the dish, run Ethernet, change the router, wait for firmware, or escalate.

Ping drift: the number speed tests hide

A normal residential Starlink session often sits between 25 and 60 ms. That is good enough for video calls, SaaS apps, and casual gaming. The failure pattern is not a median of 55 ms; it is the jump to 140 ms every three minutes, or a 2 percent ping drop rate that lines up with handoffs. A download speed test averages over time. Your meeting software does not. It reacts to the bad second.

Start with three tests. Run a wired speed test at 7 am, 8 pm, and 11:30 pm. If 7 am and 11:30 pm show 35 to 55 ms but 8 pm drifts to 120 to 180 ms, congestion is likely. If all three drift in the same rhythm, look at obstruction or firmware. If only WiFi devices drift, while Ethernet stays clean, your router or mesh path is the issue. Our Starlink gaming guide goes deeper on genre-specific latency, but the debug-data rule is simple: sustained drift beats advertised speed as the reliability signal.

Do not overreact to a single 250 ms spike. Satellite networks are dynamic, and low Earth orbit systems require beam and gateway decisions that can make one packet look ugly. React when the graph shows repeated plateaus, repeated drop clusters, or drift tied to exact times of day. The time correlation is what separates network congestion from a local installation fault.

“For real-time work, I draw the line at 100 ms sustained drift. A 45 ms median with five 130 ms plateaus per hour is worse than a steady 70 ms link, because jitter forces conferencing apps to buffer and hide loss.”— Hommer Zhao, SatSpeedCheck network analyst

Obstruction percent: when a tiny number is not tiny

Obstruction is the field most owners underestimate. One percent sounds harmless until you remember that outages do not distribute evenly. A branch can block a specific satellite path for five seconds during a handoff, then disappear from the problem for the next 20 minutes. Streaming apps hide that with buffers. VPN, Zoom, FaceTime, VoIP, and first-person games expose it.

Use this threshold ladder. Under 0.5 percent is excellent. Between 0.5 and 1 percent is a strong target for remote work. Between 1 and 2 percent is usually fine for streaming but suspect for calls. Between 2 and 5 percent, expect visible interruptions. Above 5 percent, stop tuning software and fix the site. The fastest next step is the obstruction checker with a wide-angle sky photo from the actual mount point.

If obstruction increased after a month of good service, inspect physical changes before blaming the network. Spring leaf-out can move a site from 0.8 to 3 percent. A pole can rotate a few degrees after wind. Snow melt can leave ice on the lower edge of a dish. A new RV parking angle can put an air conditioner shroud in the view. Debug data tells you the symptom; your site survey tells you the cause.

Software version: beta, rollout, or real defect?

The softwareVersion field matters because Starlink updates both dish and router behavior without asking for a maintenance window. A beta build does not mean the dish is broken. It means your system is on a staged release channel or received a build before every terminal in your region. Most updates settle quietly after one reboot and a few minutes of satellite reacquisition.

Treat beta firmware as a suspect only when three facts line up: the version changed, the problem started after that timestamp, and the failure persists for more than 24 hours. If outages went from 40 seconds per 12 hours to 14 minutes per 12 hours after a new version, keep the exact version string and screenshot the outage graph. If the version changed but the obstruction map also rose from 0.7 to 4.1 percent, the firmware is probably not your root cause.

SpaceX has said in a Starlink network update that its engineering target is stable 20 ms median latency with minimal packet loss, and that goal requires continuous network and software changes. In practice, that means a quiet update can improve latency one week and expose a router or mesh bug the next. Debug data gives you enough evidence to avoid vague support tickets.

“I do not escalate beta firmware by name alone. I escalate when the same version produces a measurable step change: 10 extra outage minutes per 12-hour window, 2 percent new ping loss, or repeated thermal/router alerts after a clean reboot.”— Hommer Zhao, SatSpeedCheck network analyst

Outages: match the label to the fix

Outage counters are where the Statistics page becomes useful. Network issue, no signal, booting, searching, obstructed, and router-related messages point to different fixes. Network issue usually means Starlink-side routing, gateway, or capacity behavior. No signal and searching point toward dish view, cable, mount movement, or local weather. Booting points toward power, cable seating, or firmware. Router alerts point toward local networking.

The threshold depends on your application. For a cabin streaming Netflix, 2 minutes of short outages in 12 hours may be invisible. For a telehealth call, 30 seconds at the wrong time is too much. As a support threshold, use 10 or more outage minutes in 12 hours when obstruction is under 1 percent and weather is normal. That combination says you have ruled out the easy local explanation.

Power users should also check plan behavior. If outages are low but speeds collapse during peak hours after heavy use, compare your plan against Starlink data caps and run the plan picker. A deprioritized plan can look like a network problem when the real issue is capacity scheduling.

Router, WiFi, and cable fields

Debug data often saves you from moving a perfectly good dish. If the app shows clean Starlink uptime but your laptop drops, inspect router uptime, mesh node status, WiFi band, and device signal. A router in a hot window can behave worse than a roof dish in rain. A mesh node one wall too far away can add 40 ms of jitter while the Starlink link itself remains clean.

Test in this order: Ethernet if your hardware supports it, then one device within 6 feet of the router, then your normal room, then mesh. If the first two are stable and the last two are not, do not open a Starlink ticket yet. Move the router, reduce mesh hops, split congested devices, or compare with a known-good router. The Starlink speed optimization guide covers practical WiFi fixes after the debug data proves the dish is not the bottleneck.

Cable fields matter most when problems appear after installation, travel, or wind. Inspect the SXPOE connector seating, sharp bends under 4 inches radius, crushed cable under a window, and water at the entry point. A cable fault can masquerade as firmware because it appears intermittent. The difference is physical correlation: bumps, wind, or router movement make cable faults worse, while firmware faults follow time and version patterns.

A 20-minute debug workflow

Start with a screenshot of Statistics, Debug Data, and Outages. Then run a wired or close-range WiFi speed test. Record download, upload, latency, jitter if available, obstruction percent, and outage minutes. Reboot only after you capture the evidence; rebooting first erases useful timing clues.

Next, compare the symptom to the field. Slow speed with normal ping points to congestion, data priority, or WiFi capacity. Normal speed with bad ping drift points to jitter, obstruction, router, or handoff behavior. Repeated no-signal outages point to sky, cable, mount, or weather. Router-only warnings point to local networking. Beta software plus a new outage step-change points to a release issue.

Finally, collect a second sample 6 to 12 hours later. Starlink is time sensitive. A clean noon test and dirty 8 pm test is a capacity story. A dirty test after rain, snow, or wind is a physical story. A dirty test on only one device is a LAN story. When you have those two samples, support has something concrete to work with: version, outage minutes, obstruction percent, latency drift, and timestamps.

FAQ