Build1 distinct publisher3 min readPublished
A frame-level listener run beside a 60-second poller found 16 outage episodes to the poller's 7, and the surviving durations read 1.8x too long. The availability number still looked fine.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The boundary between the two duration populations sits just under 60 seconds, and 60 seconds is the poll interval, not a property of the radio [9]. The line in the data was drawn by the instrument, and the tape then reported that line as a fact about the link.
The reason this survived two weeks of quotation is arithmetic. Sixteen episodes at a mean of 55.3 seconds is about 885 seconds of real dark time inside a 7,200-second window [21]. The eight blips the poller never saw account for roughly 114 of those seconds, about 13% of the total [20]. Lose half the events, lose an eighth of the downtime: recorded dark time comes out at 9.58% against a real 12.28%, or 78% of the truth [12][13]. Anyone checking the poller against an availability figure would have passed it. Anyone checking it against a rate would have been out by 2.3x, and the median duration by 1.99x [5][11].
The over-statement is a separate defect with a separate cause. Each row's duration is down-checks times the tick, written honestly as a lower bound, ">=60s dark" [14]. Five of the seven rows land near the truth. Two claim roughly double, and those two are exactly the rows where the remediation ladder climbed, four down-checks and six against one everywhere else [15]. The ladder's rungs are reassociate and bounce, so the monitor tears the link down itself and the seconds it spends doing that land inside the episode it is recording [16]. For those rows the instrument is a participant in the event it is measuring.
Note also that the long mode had eight members and the tape has seven rows, so the poller missed one episode above its own tick as well [22]. And one piece of arithmetic the writeup does not do: if a 14.22-second blip arrives at uniformly random phase against a 60-second check, it covers a poll about 24% of the time, so eight of them should have produced roughly two rows rather than none, and a clean sweep of eight misses has about a one-in-nine likelihood [23]. That is not evidence of a mechanism, but it is a reason to stop assuming the blips and the tick are independent.
The general shape holds well beyond one wifi dongle. Undersampling a duration distribution leaves the integral roughly intact while destroying the distribution, because the mass you drop is by construction the low-mass end [17]. Sums over time keep looking healthy; counts, means, medians and percentiles are wrong by an amount the record contains no trace of [18]. That is the trap in the dev.to writeup worth carrying away: one poller feeding a dashboard that shows uptime while engineers reason from it about how often and how long is answering three questions and is only correct for the first [24].
Ranked by verification strength, evidence, and original report placement.
Undersampling a duration distribution destroys the distribution while leaving the integral roughly intact, because the mass lost is by construction the low-mass end.
Any metric that is a sum over time will look healthy, while any count, mean, median or percentile is wrong by an amount nothing in the tape can reveal.
The poller asks every 60 seconds whether the wifi link is associated; if not it opens an episode, climbs a remediation ladder, and writes a RECOVERED line when the link returns.
The poller's tape has been quoted in incident notes for two weeks: counts per day, rates per up-hour, trend lines, and an argument about a failing USB dongle.
The author added a second instrument, a listener on the 802.11 management plane that sees DISCONNECT and CONNECT events with microsecond timestamps, and compared both over the same 120 minutes.
The frame plane recorded 16 episodes over the window; the poller's tape has 7 rows.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Internally consistent single-operator measurement, unreplicated
The core comparison is quantified and arithmetically self-consistent: 16 episodes at mean 55.3s is about 885s, which matches 12.28% of the 7,200-second window; 7 rows at mean 98.7s is about 691s, matching the stated 9.58% and 78% capture rate; the short mode is reported value-by-value (14.1-14.5s, sd 0.14s). Against that, everything comes from one author, one link, one node and one 120-minute window, the frame-plane listener is assumed to be ground truth without validation, and no raw capture or poller source is published for recomputation. Sufficient to trust the described episode but not the general claim.
Confined to the author's own deployment
The only observable uptake is internal to one setup: the polled record was in active use as the team's sole outage record and was quoted in incident notes for two weeks, and the reported duration-field defect produced an accepted acting_rung fix in that same poller. There is no third-party deployment, release, benchmark, package or downstream adoption of the method or the fix anywhere in the supplied material, so adoption is real but minimal in scope.
Mildly overstated generalisation over a careful measurement
The measurement itself is hedged and specific, and the piece volunteers the inconvenient result that the availability number looked fine, which cuts against overstatement. The gap comes from scope: a title and framing addressed to 'your outage monitor', plus an explicit claim that this is 'a general property, not a quirk of my data', rest on one 120-minute window, one wifi link and 16 episodes, with the frame-plane listener unvalidated and no raw data released. Modestly positive rather than large, because the mechanism argued - censoring at the tick removing the low-mass end - is plausible and internally consistent.
Low commercial incentive, credibility-driven
The one supplied source is an individual practitioner write-up on a developer blogging platform. No product, vendor, sponsor, funding round, pricing or license is promoted, and no named commercial monitoring tool is criticised or endorsed; the instrument under attack is the author's own poller, and the author credits a better fix than the one he proposed. Residual incentive is reputational - platform engagement and a striking headline number - which is why this is low rather than negligible.
Moderate: coherent numbers, single unreplicated source
Confidence is held up by arithmetic that reconciles across every reported figure and by a mechanism (censoring at the polling interval, self-healing action counted as outage) that explains the pattern without special pleading. It is held down by total dependence on one publisher and one author, absence of raw data or code, an unvalidated ground-truth instrument, a two-hour sample of 16 episodes, and the non-trivial chance that missing every short episode was partly luck. Adequate for treating the described failure mode as real and worth checking locally; not adequate for treating the quantitative ratios as generalisable constants.
build
Three manual interventions in a month, and every guard was working as designed1 distinct publisher
build
Six MariaDB versions, one real difference: the only reason to leave 10.6 is the July 2026 clock1 distinct publisher
build
Force the tool call, then hand Lightsail a long-lived key1 distinct publisher
build
AI-written code fails the same four ways, and every gate you own reports green1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 26, 2026