Changelog — ClumsyLinkWatch

v0.9.1 Generally Available Aug 29, 2026

DEGRADED stops crying wolf

A latency breach now has to persist before it counts — three of the last five samples over threshold, not one. This is the fix, and everything else here follows from it. Loss has always been measured as a rate over a window; latency was being judged on a single probe against a threshold derived from the connection’s own baseline. At roughly 17,000 samples per rung per day, that guarantees a healthy link crosses the line several times a day through nothing but ordinary jitter, and each crossing opened and closed an event within seconds. Replayed against fourteen days of real samples from a Starlink connection, the old rule produced 502 DEGRADED events and the new one produces 6 — and the six are the ones with sustained packet loss behind them
The ISP-hop rung’s latency is no longer evidence — that rung works by timing an ICMP time-exceeded reply, which a router generates on its control plane, a path that is rate-limited and deprioritised by design. The figure describes how busy that router’s processor is, not how long your traffic takes. On the connection above it read a median of 46ms against a 32ms p99 for the internet anchors, with 13% of samples over 60ms, and it was the single largest source of false DEGRADED events. The rung keeps its full weight where it is sound: an unreachable first hop still classifies as LAST_MILE_DOWN, and its packet loss still opens a DEGRADED event. Only the latency number is set aside, because only the latency number is an artefact of how the measurement works
The DNS rung reports the median resolver, not the first one — the rung stands for “can this machine resolve names, and how fast,” but it was reading whichever resolver happened to be configured first. For anyone running a local Pi-hole or AdGuard, that is a box whose cache misses take tens of milliseconds while three public resolvers answer in two, so its own cache behaviour was being recorded as a network fault: across 437 events on the test connection, the local resolver was the slowest of the four in 352 of them. Reachability is unchanged — the rung still passes if any resolver answers
A reported latency figure is the level that was held, not the worst sample — the number in an event, a report and a webhook alert is now the median across the confirming window. A document claiming 900ms because one probe spiked is the kind of detail that gets the whole thing dismissed
Nothing was loosened to achieve this — no threshold moved, and the Sensitivity settings mean exactly what they did before. If you had already raised your multiplier or floor to quieten the noise, this is a good moment to put them back: the tighter settings should now hold, and a tighter threshold is a stronger report. What changed is that a threshold crossing must be sustained to be believed, which is a rule about evidence rather than a rule about tolerance — an event that never opens was never claimed, whereas discarding short events after recording them would be deleting evidence

v0.9.0 Generally Available Aug 18, 2026

The uptime number now means what it says

Uptime is measured over the time the app was actually watching — this is a correction, and for some of you the figure will go down. The percentage used to divide outage time by the whole calendar period, which meant every hour ClumsyLinkWatch was not running sat in the denominator and quietly counted as uptime. Run the app for four hours of a thirty-day window, catch six minutes of outage, and the old report claimed 99.99% uptime for a month it observed half a percent of. A report generated over a period with no data at all printed a confident 100%. The figure now describes observed time only, and where nothing at all was observed it prints a dash and says the report describes nothing rather than inventing a number. If yours dropped, the new one is the accurate one — and it is the one that survives being read by someone looking for a reason to dismiss it
Every unmonitored span is now listed in the report — with its exact start, end and duration, in the body rather than buried in an appendix, alongside the share of the period that was covered. The methodology paragraph explains the change so a support representative reading it understands what the denominator is. This is deliberate: a reader who can see the gaps can check the arithmetic, and a reader who discovers a gap you did not disclose stops believing the rest of the document
Gaps show on the timeline too — hatched, on every zoom level, on the dashboard and the day-cell views. Sleep and host gaps have been described as rendering this way since the first release; they never actually could, because nothing was recording them in a form the timeline could read. They can now. An outage that was still open when monitoring stopped is cut off at the gap rather than drawn straight through it, since what happened in between was not measured
“Your machine was asleep” is only claimed when Windows said so — a suspend confirmed by a Windows power event is recorded as HOST_SLEEP, as before. A span where the only evidence is that the clock jumped is now MONITORING_GAP, because a closed app, a powered-off machine and a hibernate that fired no event are indistinguishable from the clock alone. Both are excluded from uptime and downtime exactly as before; the difference is only in what the report is willing to assert about why. An evidence document should not make a claim about your hardware that it cannot support
Start with Windows — new in Settings → General → Startup, off by default, with an option to start straight to the tray. Given the change above, this matters more than it used to: a monitoring tool you have to relaunch by hand after every reboot collects a record with holes in it, and those holes are now visible in the report rather than silently flattering the total
The dashboard uptime figure got the same correction — it previously checked only that monitoring had begun before the 24-hour window started, then divided by the full day, so an app closed for twelve of those hours scored the closed half as uptime. It now uses the same observed-time calculation the report does, and says what share of the window it measured whenever that is not effectively all of it
Fixed: a speed test appeared to stop if you changed screens — it never actually stopped. The run continued in the background and its result still reached History; what was lost was the live progress display, because leaving the Speed Test screen discarded the part of the app tracking it. The run now survives navigation and the tab marks itself while one is going. The reason this was worth more than a cosmetic fix: with the display reading idle, the obvious thing to do is press Run again, which started a second test alongside the first. Two tests sharing one connection each measure roughly half its real speed and record that as your result, and the pair of them defeated the guard that stops a speed test from being logged as a fault against your own link
Fixed: the Windows time service command in the app did not run — where the host clock could not be checked, the app offered a command to fix it that used && between the three steps. That is a syntax error in Windows PowerShell, which is what “run as administrator” opens on Windows 11, so nothing executed at all. It now uses the correct separator and names the shell to paste it into

v0.8.0 Generally Available Aug 6, 2026

The backup connection you are not using, and the wireless link you might be blaming them for

Your standby connection is now monitored too — until now the app watched whichever link your traffic was actually leaving through, which means a backup WAN could have been dead for weeks and you would find out at the worst possible moment. Every WAN link you are not using is now probed in its own right, on the same ladder and through the same classifier as the active one, so an outage on your standby means exactly what it means on your primary. Standby links are probed every 15 seconds rather than every 5 — matching the active cadence would roughly double the traffic this tool puts on the wire to watch a path nobody is using, and a link carrying nothing can afford to be noticed 15 seconds late. That tightens to 5 seconds the moment one starts failing, because a failover figure is only as precise as the sampling either side of it
Every rung is bound to the link it is testing — this is the part that makes the above trustworthy rather than decorative. A probe that is not explicitly bound to an adapter measures whichever connection Windows felt like using and reports the result as that link’s, which is evidence that looks perfectly valid and is wrong. All five rungs are bound, including DNS, which needed a small purpose-built resolver because Node’s own offers no way to say which connection to ask from. Verified on a dual-homed machine: bound to a downed adapter the probe correctly reports unreachable while the live adapter answers, even when both share a subnet and a gateway
Wi-Fi signal strength, read properly — a weak wireless link produces the same symptoms as a bad last mile, loss and latency on everything above the adapter, and the app had no way to tell them apart. It now reads signal strength, channel, radio type and link rates from the Windows Native Wifi API directly rather than by scraping a command’s output — that output is translated into the system language, so a parser keyed to English words returns nothing on a German or Japanese Windows while appearing to work perfectly. Band is deliberately not shown: the API reports a channel number, and channel numbering overlaps between 5 GHz and 6 GHz, so a derived band label would print the wrong one often enough to matter in a document you are handing to someone adversarial. The channel and the radio type are exact, so those are what you get
A weak signal is raised as a doubt, not used to erase the outage — where the radio was genuinely in trouble during a degraded span, the app says so and quotes the measured dBm against the threshold. It does not move the event out of the ISP-attributable table to do it. The outage stays counted, and the suspicion is printed beside it in the report. This is the deliberate choice: a rule that wrongly excused a real ISP fault as “your Wi-Fi was weak” would be worse than having no rule, because the ISP-attributable table is the one thing this product exists to produce. A reader who finds an omission stops trusting the document; one who finds the tool arguing against its own case starts trusting it. Where signal strength cannot be read at all — no adapter, wireless service stopped, driver refusal — nothing is flagged and nothing is excluded, because a missing reading must never become a claim that the host was wired
Fixed: the app could pick a dead adapter as your connection — the default-route lookup did not check whether the adapter behind a route was actually up, so on a machine with more than one network interface it could settle on one that was disconnected and report everything from that vantage point. This is the kind of fault that quietly poisons everything downstream of it rather than announcing itself

v0.7.1 Generally Available Aug 4, 2026

Which connection you are on, whether the dish has moved, and the findings the app was keeping to itself

Connections, on the dashboard — the app now identifies the ISP your traffic is actually leaving through, by name, ASN and public address, and updates when that changes. Where it has seen more than one, it ranks them by how much observed time each has carried traffic, so the one you use most reads as Primary and the other as Secondary, with the live one badged Active now. Connections are identified by the operator that owns the address, not by the address itself, so a dynamic IP renewing on the same provider is correctly not treated as a second connection. It collapses to a single line while there is nothing to report
Failover timing in the report — a new Connections & Failover section states how long each connection carried traffic, every switch between them, and how long you were actually offline across each one. That last number is the thing dual-WAN owners have not been able to get: whether the second link took over cleanly or left a gap, and how big. Switch times come from a public-address check that now also fires the moment any fault clears, so a failover that caused an outage is timed to within seconds of recovery. A switch with no outage around it is reported as no gap observed rather than as an instant handover — the app will not claim a precision it does not have
Alignment lock for Starlink — lock the dish’s aim while it is pointed the way you want it, and the app records that direction as a reference, then checks once a minute — whether or not the Starlink tab is open — whether the dish has moved off it. Wind, snow load, a loosened mount or someone knocking the pole all present as a mysterious rise in obstruction; this turns that into a date and an angle. Both gauges gain a ghost needle at the locked position, and there is a drift chart over the last 30 days. An actuated dish re-aims itself after a reboot, a stow or a firmware update, so readings taken while it is unsettled are discarded, and a deviation has to hold for a configurable dwell before it counts as a move. Deviation is measured as the true angle between two pointing directions, so it is not fooled by the compass wrapping past north or by rotation becoming meaningless near vertical
Dish alignment in the report — a section that answers the standard brush-off before it is made. “Something must be obstructing it” and “your dish has shifted” put the fault back on you and end the conversation; a line stating the dish held within a fraction of a degree of a fixed reference for the entire period closes that off with a measurement. It reports movement just as plainly when the dish did move, with the date, because a report that only ever exonerates its author is not evidence
Outage timing, in the app — the recurring-pattern analysis added in 0.6.0 only ever appeared inside a generated report. It is now a panel on Diagnostics, running the same analysis over the same data, so you can see “your outages cluster on weekday evenings” without producing a PDF first. It still withholds a day-of-week claim until the monitoring window is long enough to support one, and now says so on screen rather than going quiet
Host clock on Diagnostics — every timestamp in every report comes from this machine’s clock, and the app has always checked it but only mentioned it inside the report’s provenance block. It is now a standing readout, and it warns if the clock is unsynchronised or has drifted past two seconds. That is something you want to find out before you build a case on those timestamps, not after
Filtering on the Events screen — filter by attribution (ISP, local, excluded), by classification, by date range, and hide events you have already acknowledged, with a count of how many of the total are showing. “Just show me the ISP’s faults from last month” was previously a matter of scrolling
Recognisable ISP names — address registries return the legal entity, which is frequently not what anyone calls the service. Starlink comes back as “Space Exploration Technologies Corporation”. The app now shows the name you would use, with the registered entity underneath rather than instead of it — the legal name is what a support representative will recognise on a ticket, so both are worth having
The dashboard reads top to bottom again — status, then findings, then the timeline, then the probe ladder, then connections. The timeline had drifted to the bottom of the screen despite being half of what this tool is for
Fixed: the host clock panel reported “not synchronised” when it had simply failed to ask — Windows’ time service ships set to Manual on many installs, and when it is stopped the query returns an error rather than a status. That error was being read as a finding, so the app — and worse, the report’s provenance block — stated that the host had not been synchronised to an internet time source. It had determined no such thing. A failed query is now reported as a failed query, says plainly that it is not a statement about whether the clock is right, and names the stopped service with the command that fixes it. A genuinely unsynchronised host is still reported as unsynchronised
Fixed: bufferbloat’s low-confidence note read as though it were about your speed test history — it said “too few samples were taken”, which anyone with months of runs reasonably took to mean their runs were being ignored. The samples in question are latency readings inside a single test, and a grade never pools across runs. The note now says so
Fixed: links in About navigated the app window away from itself — opening the website link replaced the entire interface with the remote page, in a window with no back button. External links now open in your browser, and any attempt to navigate away from the app is caught centrally rather than link by link
A run count on Speed Test history — beside Clear All, so you can see how much history is behind the averages and patterns, and what Clear All would remove
A donation link in About — ClumsyLinkWatch is free for personal use and staying that way. The ask is made once, in About, and nowhere else
Fixed: equipment-restart detection never actually fired — 0.6.0 announced that the report would flag gateway outages matching an ISP-pushed restart. It could not. The check requires corroborating evidence beyond the outage simply being a plausible length, and nothing in the app was gathering any, so the assessment declined to call every outage it was ever shown. It now reads the gateway’s address entry on the local network across each outage — a rebooting device keeps its hardware address but has to be re-learned, while an address that genuinely changes means the equipment was replaced rather than restarted, which rules a restart out instead of supporting it. If you enabled this in 0.6.0 and never saw a flag, that is why

v0.6.1 Generally Available Jul 30, 2026

The dashboard now reads like an instrument

Uptime is on the dashboard — the number this whole tool exists to produce used to live only inside a generated report. It is now the headline figure on the main screen, at a size you can read from across the room, with the downtime and outage count behind it. It shows a dash rather than a reassuring percentage until monitoring has genuinely covered a full 24 hours — no figure is claimed for time the app was not watching
A live latency trace — the last five minutes of round-trip time, drawn under the status reading and updating every probe cycle, with your link’s own normal latency marked as a dashed reference. It scales to your connection rather than a fixed range, so it is just as readable on 8ms fibre as on a 600ms satellite link, and it turns red while a fault is standing. Failed probes leave a gap rather than plotting as zero
The probe ladder is now drawn as a ladder — five rungs stacked from your own machine at the bottom to the open internet at the top, with a probe climbing the spine each cycle. When something fails the climb stops at that rung, so the picture tells you where the fault is before you read a word. Each rung says what it actually represents (“Gateway · your router”, “ISP Hop · their first hop”) and a line underneath states the finding plainly — including, when your own equipment answered, that the fault begins upstream of your property
Four standing findings at a glance — whether the link is currently fit for a call, how it behaves under load, whether your DNS resolver is the slow part, and how many ISP-attributable outages there have been in 24 hours with how long ago the last one was
Whose fault it was, in words — the event list now carries a severity stripe and a literal ISP / LOCAL / EXCLUDED tag beside every event, instead of relying on text colour alone. That reads correctly if you are colour-blind, and it survives being screenshotted into a support ticket, which is where these lists tend to end up
Resolver comparison as bars — the DNS panel draws the comparison instead of asking you to compare numbers in a column. Failure rates only appear when one of them is actually non-zero
Settings no longer scrolls or jumps — it was one long scrolling pane that shifted position every time you switched tabs, because each tab was a different height and the dialog re-centred itself. It is now a sidebar of seven focused sections at a fixed size, and it only scrolls if your window is genuinely too short for a section. The Event Detail window had the same jumping problem and got the same fix, so it no longer moves while you are typing case notes
Shorter explanations — the help text under Settings controls was doing too much explaining. Every caveat that mattered has been kept, including the one that matters most: loosening a threshold changes what a report can prove

v0.6.0 Generally Available Jul 29, 2026

Evidence you can defend: resolver comparison, case notes, outage timing, and report provenance

Your ISP's DNS, measured against the public resolvers — the app now finds your own configured resolver (usually your router, forwarding to your ISP) and asks it the same question, at the same moment, over the same connection as Cloudflare and Google. The Dashboard and the report both show typical response time, failure rate, and the query count behind each. "Your ISP's DNS is the slow part" is now a statement the app can actually make — and it stays silent below 200 queries rather than guessing
NXDOMAIN hijack detection — asks every resolver for a hostname that cannot exist. A resolver handing back an address instead of a "no such name" answer is hijacking the response, which breaks far more than web browsing, and is the operator's doing rather than yours
Case notes on outages — attach the ticket number, who you spoke to, what they promised, and a follow-up date to any outage. They show in the event list and carry into the report as a Case notes column, so a complaint can set broken promises against measured downtime. Nothing you type here influences how an event is classified
Outage timing analysis — the report now looks for recurring patterns: same time each day, same day each week. A documented nightly pattern is very hard to wave away. It is deliberately conservative — no claim below 8 outages, a cluster must clearly beat chance, and it will not assess day-of-week patterns until the monitoring window is long enough to tell "it always happens on a Tuesday" apart from "monitoring only ran on a Tuesday"
Report provenance block — every report now states the tool version, the exact period, how many samples it drew on, and whether the host clock was synchronised to an internet time source (with the measured offset). Every timestamp in a report rests on that clock being right, and until now that was assumed rather than shown. Includes an integrity checksum so two copies of a report can be confirmed to describe the same measurements — it is not a signature and does not establish who produced a file
Possible ISP-pushed equipment restarts — providers reboot customer equipment on their own schedule, and that used to read as purely your fault. Where you have told us the gateway is ISP-supplied equipment, the report's appendix now flags outages matching a restart signature and shows the reasoning. The classification never changes on its own: it stays a local fault and stays out of your ISP-attributable downtime
Latency-under-load measurement reworked — bufferbloat grading now discards latency samples taken in the gaps between transfers instead of averaging them in, grades on both typical and worst-case latency rise, and takes its idle baseline from a low percentile so background traffic in your house cannot flatter your router. Low-confidence runs now say so. Existing grades may shift as a result — the top-grade threshold changed, so a grade can move without your network changing
Fixed: brief outages disappearing from reports — an outage that started and ended inside a single probe cycle was dropped from both the outage table and the appendix, so the report could show nothing while the database held a real last-mile failure. Sub-minute outages also displayed as "0m"; they now show in seconds
A new one-time Settings question asks whether your gateway is ISP-supplied equipment or your own router. It is used only to decide whether an ISP-pushed restart is even possible; leaving it unanswered simply keeps that detection off

v0.5.1 Generally Available Jul 28, 2026

Anonymous usage telemetry, on by default and fully disclosed

Anonymous product telemetry — matches ClumsyFileMover and ClumsyNetWatch: app startup, app version/OS/architecture, that a report was generated (and its format), and that Starlink detection was turned on. No probe results, events, IP addresses, ISP name, account number, location, or anything else you monitor or type into a report is ever sent. On by default; turn it off any time from Settings → General → Privacy
Privacy Policy updated to disclose exactly what's collected and how to opt out, before this shipped rather than after

v0.5.0 Generally Available Jul 28, 2026

Starlink event log, live history charts, and a real-time signal view

Starlink's own event log — the Starlink page now pulls the dish's internal diagnostics log directly: every outage and packet-loss event it has recorded since its last reboot (severity, reason, start time, duration), independent of ClumsyLinkWatch's own monitoring
Real-time throughput and loss/latency charts — downlink/uplink Mbps and dish-measured loss and latency, bucketed from the dish's own last-15-minutes history, with pop ping latency shown against Starlink's own published 20ms median-latency target
Live signal view — a satellite/dish beam animation and lit signal bars derived from real latency, loss, obstruction, and alert state, so the Starlink page reads at a glance instead of requiring a second look at the numbers
Redesigned Starlink page — status, uptime, and a Copy Diagnostics button up top, then alignment gauges and the obstruction map side by side, then throughput and loss/latency charts, then the event log
Fixed the Starlink page showing "detection is off" for up to a minute after enabling "I use Starlink" and switching to it, instead of refreshing immediately

v0.4.0 Generally Available Jul 28, 2026

Real Starlink dish telemetry, tabbed Settings, and DEGRADED sensitivity control

Starlink dish integration — turn on "I use Starlink" (Settings → General) to pull real telemetry directly from your dish over its own local diagnostics service, no separate account needed: connection state, uptime, pop ping latency/loss, software version, active alerts, live Rotation/Tilt alignment gauges, and a real-time Obstruction Map rendered from the dish's own sky-obstruction data. Off by default — the app never probes for a dish unless you turn this on, and the dish's LAN address is configurable for nonstandard network layouts
DEGRADED sensitivity control (Settings → Sensitivity) — Strict/Default/Relaxed presets plus custom latency multiplier, latency floor, and loss threshold values, with a Reset to Defaults button. Fixes DEGRADED firing on ordinary jitter for low-baseline rungs (a fast gateway, or a DNS baseline that happens to be a couple of ms), and Relaxed specifically suits satellite links like Starlink
Settings is now tabbed — General, Alerts & Remote, Speed Test, and Sensitivity, instead of one long scroll
Clear All for both the Events list and Speed Test History, with a confirmation showing the count before permanently deleting
Fixed a startup race where Speed Test History could stay empty until a new test ran, instead of loading on launch

v0.3.3 Generally Available Jul 27, 2026

Remote status page: full app parity

The Remote LAN Status page (Settings → Enable Remote LAN Status) now shows everything the desktop app does, not just status/ladder/events: an ISP/WAN panel, the 14-day latency trend chart, and a full Speed Test section (latest result, day/hour pattern heatmap, and recent run history)
Tap any event in the Remote Status page's Recent Events list to open the same evidence popup the desktop Event Detail view shows — full probe-ladder/DNS/quorum results, the "why" for DEGRADED, and a "what to do" suggestion — all from your phone

v0.3.2 Generally Available Jul 27, 2026

Speed test reliability fix

Fixed the speed test failing outright on slower or flakier connections with "Connection failed... gave up after 20 retries" — the test previously required a single 100MB+ request to complete without a hitch or it aborted the whole run; chunk sizes are now capped at 25MB and total transfer per run cut from over 1GB to roughly 200MB, matching the estimate already shown in Settings
If a connection hiccup still happens mid-test, the app now keeps whatever download/upload/latency numbers it already measured instead of throwing the whole result away
Speed Test History now updates immediately after a run finishes instead of waiting up to a minute for the next background refresh

v0.3.1 Generally Available Jul 27, 2026

Event detail & actionable alerts

Click any event in the Events list to see the full evidence behind it — every probe-ladder rung, DNS resolver, and quorum anchor result, plus a plain-English "why" for DEGRADED — with a Copy Summary button to paste it into a ticket or message
Discord/Slack webhook alerts now include the specific DEGRADED reason(s) instead of just the bare class name, and a "What to do" line once the event resolves
Added the same "What to do" guidance to the Event Detail view and the copyable summary — a plain-English suggestion tailored to the fault class (and, for DEGRADED, which rung tripped it)

v0.3.0 Generally Available Jul 27, 2026

Scheduled speed tests & multi-screen UI

Scheduled speed tests — run automatically every 30 min / 1h / 4h / 12h / 24h (off by default), with a live data-cost estimate and an option to skip while a fault is active
Speed test history — every run (manual or scheduled) is saved, sortable by worst download/upload/latency, with a day-of-week × hour-of-day heatmap that flags recurring slow windows (e.g. peak-hour congestion) automatically
Self-interference guard — a running speed test now suppresses DEGRADED classification, since a real speed test saturates the link enough to cause latency spikes that could otherwise falsely trigger against itself
Evidence reports now include a speed test summary and the same recurring-pattern detection when tests exist in the period
Rebuilt the app around four screens (Dashboard, Diagnostics, Speed Test, Events) instead of one long scrolling page

v0.2.2 Generally Available Jul 27, 2026

Why DEGRADED was triggered

DEGRADED events now record and show exactly why — which rung (gateway/ISP-hop/DNS/quorum), whether it was loss or latency, and the measured value against the threshold it crossed
Live status card shows the current breach(es) in real time while DEGRADED, not just after the fact
Evidence reports now include the same detail in the outage table instead of just the word "Degraded"
The remote LAN status page and the event list tooltip show the same detail

v0.2.1 Generally Available Jul 27, 2026

Remote LAN status page redesign

The remote status page (Settings → Enable Remote LAN Status) was just a bare classification and timestamp — it now shows the full probe ladder with live per-rung latency, rolling loss, a captive-portal warning banner, and color-coded recent events, styled to match the app itself instead of a placeholder page

v0.2.0 Generally Available Jul 27, 2026

SLA credit calculation & per-rung baselines

SLA credit dollar calculation — enter a monthly bill amount in the report generator and get a prorated credit figure for ISP-attributable downtime
Per-rung baseline auto-tuning — gateway, ISP-hop, and DNS rungs now get their own DEGRADED baseline instead of only the quorum rung, catching a rung that's quietly slowed down even when the rest of the link looks fine
winget / Chocolatey / Scoop packaging manifests prepared and verified against this release

v0.1.4 Generally Available Jul 27, 2026

Settings window fix

Fixed the Settings window sometimes doing nothing when clicked — the app could ask for saved settings before the local database finished starting up and never try again; it now retries until the database is ready

v0.1.3 Generally Available Jul 27, 2026

Check for updates from About

Added a Check for Updates button to the About screen, with inline status (checking / up to date / update available) and Download/Restart actions right there

v0.1.2 Generally Available Jul 26, 2026

Speed test fix

Fixed the built-in speed test reporting near-zero results for everyone — the renderer now loads over a registered clw:// scheme instead of file://, which was silently breaking the browser timing APIs the speed test relies on for accurate bandwidth and latency measurement
Removed the unused packet-loss measurement phase, which could throw an unhandled error in some environments without affecting the visible results

v0.1.1 Generally Available Jul 26, 2026

Auto-update verification

Verification release for the in-app auto-updater — no user-facing feature changes from v0.1.0

v0.1.0 Generally Available Jul 26, 2026

Initial release

Probe ladder — five-rung fault detection: adapter, gateway, ISP first hop, DNS, and a quorum of independent internet anchors, run every cycle for full evidence
Fault classification — ADAPTER_DOWN, GATEWAY_DOWN, LAST_MILE_DOWN, DNS_FAILURE, UPSTREAM_DOWN, DEGRADED, and HOST_SLEEP, with confirmation retries before anything is declared down
TTL-limited ISP-hop probing to avoid false last-mile-down readings on routers that answer traceroute but not direct ping
Monotonic-clock duration tracking so NTP corrections and DST shifts never produce impossible outage durations
Sleep/hibernate detection via Electron powerMonitor plus wall-clock gap detection, rendered as hatched timeline gaps — never counted as uptime or downtime
Adaptive probe scheduler — 5s healthy, 2s during an active event, backing off to 30s after 10 minutes down
Live dashboard — time-proportional timeline strip with hover detail, Live/24h/7d/30d zoom, 14-day latency trend chart, hop table, hardware panel, built-in speed test
SQLite-backed local history with configurable retention
Evidence reports — HTML and PDF export with methodology paragraph, ISP-attributable outage table, timeline and latency/loss charts, and an appendix of excluded events
Alerts — native desktop notifications, taskbar flash on real faults, Discord/Slack-compatible webhook alerts
Hardware panel — Starlink dish detection, network adapter visibility for dual-WAN setups
Auto-update via built-in updater