Dishylink for Windows 10 & 11: Starlink Desktop Monitoring, Alerts and Router Controls

Developed independently by David Herbert (known on GitHub as DaveyHert) under an MIT license, Dishylink is not an official SpaceX product. Instead, it is a free utility available for Windows 10 or later and macOS 12 or later, alongside browser extensions for Microsoft Edge, Google Chrome, and Mozilla Firefox. By tapping into the Starlink hardware's local network interface—and optionally pairing with a user's Starlink cloud account—it transforms a cramped mobile-only workflow into a full-screen desktop dashboard.

Desktop Real Estate Meets Local Dish Telemetry​

In a hands-on evaluation published by MakeUseOf writer Gregory Gibson, the standout advantage of running Dishylink as a native Windows application is simply having the screen real estate to view critical metrics simultaneously. Rather than swiping between isolated mobile screens, the desktop interface consolidates live traffic throughput, latency distributions, connection health, and power consumption into a single window that can sit quietly in the Windows Taskbar.

During Gibson’s testing on a Windows PC, Dishylink surfaced several practical monitoring capabilities:

• Integrated Speed and Latency Tracking: The built-in speed test—which notes that it utilizes Cloudflare’s infrastructure—clocked 267.3 Mbps download and 40.9 Mbps upload on Gibson's connection. Over a one-hour capture window, the latency panel logged a 24 ms average alongside historical ping distributions for both the router and the wider Starlink link.
• Power Consumption Metrics: Dishylink tracks live wattage and cumulative energy draw. Over that same one-hour test sample on a Starlink Mini setup, the app recorded an average draw of 18 W (0.018 kWh), giving desktop users a straightforward way to monitor energy overhead alongside network performance.
• Granular Client Inspection: The connected-device panel listed eight active clients on the network, identifying whether each device was linked via Ethernet or specific Wi-Fi bands across a Starlink Wi-Fi-Ethernet bridge. Selecting an individual client—such as a Samsung smartphone—revealed its connection to a mesh access point, live signal strength, and upload/download histories.
• Desktop Event Alerts: While Gibson noted that the official Starlink mobile app presents chronological event histories a bit more cleanly with its timeline and color coding, Dishylink holds a distinct advantage for PC users: native desktop notifications. Physically unplugging an Ethernet cable during testing immediately triggered a red-coded warning notification on the Windows desktop.

Under the Hood: How Dishylink Talks to Starlink Hardware​

What makes Dishylink particularly interesting from an IT and software engineering perspective is how it extracts this data. According to the project’s technical documentation (LOCAL-API.md on GitHub), SpaceX does not publish official documentation for the dish or router’s local gRPC API. Instead, the developer mapped the interface using the hardware’s gRPC reflection service and verified actual behavior against live hardware (rev4_panda_prod2 running firmware 2026.07.06.mr81950).

Because reflection only exposes field names and data types without guaranteeing which fields the firmware actually populates, Dishylink’s architecture has to navigate several hardware quirks:

• Ring Buffers vs. Instantaneous Polls: The dish maintains a 900-sample ring buffer (dish_get_history) ticking at 1.00 second per sample (covering 15 minutes of history), meaning the app can poll every few seconds without losing 1 Hz resolution. Conversely, the router’s client list (wifi_get_clients) has no working historical buffer; its poll rate directly dictates data resolution.
• Unpopulated Firmware Fields: The developer’s probing revealed that certain schema fields—such as wifi_get_client_history—return 900-float arrays that remain permanently at zero even under 65 Mbps to 106.58 Mbps of sustained load. Similarly, instantaneous status polls (dish_get_status) omit packet drop rates (popPingDropRate) and power draw (powerIn), requiring Dishylink to pull those metrics from the history buffer so power charts do not flat-line and outage detection remains functional.

The 3D Satellite View and the CelesTrak Dependency​

Beyond everyday network administration, Dishylink includes a 3D satellite visualization panel that renders the dish’s obstruction dome and animates Starlink satellites passing overhead.

However, users should understand what this view actually represents. Dishylink does not read live satellite tracking coordinates directly from the dish’s radio link; instead, it calculates predicted satellite positions using public orbital data. Specifically, the app queries supplemental General Perturbations (SupGP) element sets hosted by CelesTrak, which derives its Starlink orbital data from ephemeris files provided by SpaceX.

During Gibson’s hands-on test, the local dish telemetry loaded immediately, but the 3D satellite view initially failed because the app timed out while attempting to reach CelesTrak’s supplemental TLE URL over the Starlink connection. Switching temporarily to a mobile internet connection allowed Dishylink to fetch the orbital dataset, after which the visualization worked normally even after switching back to Starlink. While Gibson speculated that Carrier-Grade NAT (CGNAT) and shared public IP addresses paired with CelesTrak's rate-limiting policies might have caused the timeout, the exact cause of the routing hiccup was not definitively established.

It is also worth noting that CelesTrak’s supplemental data portal explicitly warns developers and users that the official U.S. Space Force Satellite Catalog (SATCAT) exhausted 5-digit catalog numbers in July 2026 (crossing 100,000+ cataloged objects), meaning legacy TLE formats cannot represent newly cataloged 6-digit objects and users must adhere strictly to CelesTrak's usage policies when querying orbital data.

For practical dish setup, Dishylink’s alignment panel goes a step further than the official mobile app’s simple pass/fail alignment status by displaying specific pointing measurements and suggested physical adjustments. Its obstruction map also mirrors the dish's internal tracking, though Gibson noted both Dishylink and the mobile app displayed two tiny red marks on an otherwise clear sky while reporting 0.00% total obstruction.

Router Controls, Bypass Mode, and the Account Login Wall​

Dishylink organizes its configuration tools into three primary categories:

1. Router Settings: DNS configuration, subnet selection, and enabling bypass mode for users who want to pair their Starlink terminal with a third-party router (a common upgrade for Starlink Mini owners seeking advanced features like DHCP reservations). Notably, Dishylink includes an explainer reassuring users that its dish settings remain accessible even if bypass mode is enabled.
2. Network Rules: Tools to configure data limits, time schedules, and countdown timers for client devices.
3. Dish Settings: Controls for sleep scheduling, software updates, hardware reboots, and snow-melt modes.

Here, Windows administrators will encounter an important architectural boundary. Dishylink’s developer documentation notes that as of July 2026 firmware, Starlink hardware rejects all direct LAN configuration write requests (set_config, device renames) with a gRPC status 7 error. Consequently, any action that modifies router or dish state must be routed through Starlink’s authenticated cloud endpoints (SpaceX.API.Device.Device/Handle).

Because of this firmware restriction, running Dishylink without signing into a Starlink account limits the app to read-only local monitoring and threshold alerts. For instance, if you configure a network rule to limit a family device's screen time or bandwidth without linking a Starlink account, Dishylink will monitor the usage and announce when the threshold is reached, but it cannot actively pause the device.

Even when signed in, pausing a client requires careful orchestration under the hood:

• Desktop vs. Browser Extension: Dishylink only enables device pausing in the native desktop app (and local web development host), disabling it entirely in the Chrome, Edge, and Firefox extensions. Because browser extensions run inside a sandboxed service worker and cannot reliably identify the host PC's own local IP or MAC address, the developer disabled the control in extensions so users cannot accidentally pause the very computer running Dishylink.
• Safe Configuration Writes: Because the firmware masks the lower three octets of client MAC addresses (60:74:f4:XX:XX:XX), Dishylink keys its cloud writes to the unique clientId rather than the MAC address, reading the full router state over the LAN immediately beforehand so unrelated schedules are preserved.

Practical Takeaways for Windows Users​

For Starlink subscribers who spend their workday on a Windows 10 or Windows 11 PC, Dishylink offers a compelling, purpose-built alternative to squinting at a smartphone screen. Keeping local monitoring separate from cloud authentication means cautious users can install the desktop client purely as a read-only local telemetry dashboard and taskbar notification tool without ever entering their SpaceX credentials.

If you do plan to use Dishylink for active network administration—such as enforcing device pause schedules or toggling bypass mode—treat it with the same diligence you would apply to any third-party tool relying on unofficial APIs. Review the project's open-source code and privacy documentation on GitHub before authenticating, verify your specific Starlink hardware and firmware behavior, and test any automated network rules before relying on them in production.