Loading today’s stories
Build1 distinct publisher3 min readPublished
The algorithm fits nothing and reads 256 rows per tree, so running it is cheap. The whole judgement call still collapses into one contamination number that no statistic will pick for you.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
Pick a log anomaly detector on volume, latency and secrets, not on which one is smarter1 distinct publisher
build
Optuna killed 60% of the trials and gave back 28% of the time. The gap is in the config.1 distinct publisher
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
The number doing the work is 256. Per tree, regardless of corpus size [7]. On ten thousand rows that is 2.56 percent of your data; on ten million it is 0.00256 percent, a thousandfold difference in sampled fraction for the same absolute count [1]. Training cost per tree is pinned to a constant rather than to your ingest rate, which is the property that makes this usable on telemetry. You can refit per service, per shard, per window, and the bill does not move when traffic doubles.
The reason the subsample is not a compromise, according to the post, is that a small sample keeps rare points rare, and isolation only means anything relative to the points around it [8][9]. Feed the forest everything and a recurring failure mode acquires enough neighbours inside the sample to stop being easy to separate. Everything else in the series taught the opposite shape, modelling normal first and calling the leftovers outliers, whether that is distance from a K-Means centroid or a DBSCAN noise bucket [2]. The mechanism here runs on randomness alone: it has no loss function, unlike even the local greedy split a decision tree performs; the score is an average of isolation depth over hundreds of trees, and averaging is doing all of the lifting [5][6].
Hold that next to the depth illustration. Three cuts for an anomaly, thirty for a point buried in a dense mass [4], a factor of ten [4]. But 256 is 2^8 [2], so eight balanced cuts already separate every point in a default-sized subsample. The three-versus-thirty figure is a statement about relative depth, not a count you should expect to log from a tree grown on 256 rows.
Contamination is where the engineering stops and the staffing starts. It back-solves a cut point from the observed score distribution given your estimate of the anomalous fraction [11]. Set 0.01 and you have said one in a hundred [12], so your queue depth is a function of how many points you score rather than of how bad the week was [3]. The author is blunt that no elbow or knee in a plot picks the value, and that the real inputs are how many investigations the team can absorb in a week and what a miss costs when it gets through [13]. Nothing plots that, which is inconvenient, because plots fit in a review deck and headcount does not.
Two API details belong in the alert rule before the model does. `score_samples` inverts the paper's 0-to-1 convention, so more negative means more anomalous [14]. `decision_function` then shifts that score by an offset and treats negatives as outliers, and when you specify contamination the offset is chosen to produce the expected proportion of training outliers [15]. That offset is calibrated against the training score distribution. If live scores drift, the realised flag rate drifts away from the contamination you asked for, and nothing in the API objects.
One more condition for transfer. The only operation available is a threshold on a single feature at a time [3], so an anomaly that lives in a combination of two signals is not rare in either column, and you have to engineer the combination into the feature set yourself. The write-up also skips timings and a dataset. It is a practitioner post, the ninth and final part of a series on classic ML for SREs [17]. The mechanism rests on the original paper. Whether it fits your telemetry is yours to measure.
Ranked by verification strength, evidence, and original report placement.
The original paper's score runs from 0 to 1 with values near 1 anomalous, while scikit-learn's score_samples is the opposite, so more negative means more anomalous.
scikit-learn's decision_function shifts score_samples by an offset so that negative values are treated as outliers, and when contamination is specified that offset is chosen to produce the expected proportion of training outliers.
The author writes that the inverted scikit-learn convention has bitten people and reports having watched that flip cost teams.
Isolation Forest scores how anomalous a point is by how few random cuts it takes to separate that point from everything else, with no model of normal, no loss function, and nothing optimized.
Other anomaly detectors model what normal looks like and call the leftovers outliers: K-Means flags points far from every centroid, DBSCAN puts them in the noise bucket.
Each cut picks a feature at random and a split value at random between that feature's minimum and maximum, and repeats.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 27, 2026
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.
One practitioner's notes on well-documented mechanics
The mechanics being described are stable, publicly documented behaviour, which is why they read as solid — but in our coverage all of it rests on one dev.to post recounting the original paper and the scikit-learn API from the author's own reading, with no code, version or citation a reader can follow. The post is candid that the author got contamination and the masking behaviour wrong in his own notes before correcting them, which cuts both ways: it is honest, and it shows how easily this material is misremembered.
Nothing here counts as uptake
No deployment, incident, benchmark, price or usage figure appears anywhere in this reporting. The one number that looks like traction, 256 points per tree, is a shipped default parameter — it tells you what the software does out of the box, not who is running it or on what. Treating a default as adoption would be inventing a fact.
The headline promises less than the body delivers
A title like 'the best anomaly detector I know optimizes nothing' invites you to brace for a sales pitch, and then the post spends its final third telling you where the thing breaks: masking, the inverted score that costs people afternoons, the fact that contamination is a mirror rather than a knob. The strongest practical content sits underneath the thesis, not on top of it, so if anything the framing undersells the reporting.
A series finale, not a pitch
There is no product, vendor, license or funding anywhere in the frame — the author's stake is finishing a nine-part series under his own byline on dev.to. The one distortion worth naming is structural: a finale wants a unifying thesis, and 'sometimes the winning move is to optimize less' is doing some of the work here that evidence would otherwise have to do.
Firm on mechanics, single-voiced on the rest
We can be reasonably confident about the algorithm description and the contamination correction: they are internally consistent and match the kind of behaviour that is widely documented. Confidence drops on everything experiential — the teams bitten by the sign flip, the claim that small subsamples are dramatically cheaper — because one practitioner asserting it is all the corroboration this story has.