Pick a log anomaly detector on volume, latency and secrets, not on which one is smarter

An engineer writing on dev.to has published a side-by-side of Isolation Forest and GPT-4o for log anomaly detection, and the load-bearing part is not the comparison but the triage he puts in front of it ^[1]. He argues the choice is forced by three constraints: how many GB per day of logs you generate, whether you need sub-second paging or post-incident triage, and whether your stack traces contain API keys, session tokens or PII you cannot legally ship to a third-party API ^[2].

The trigger was familiar. His Prometheus/Grafana stack was alerting loudly on CPU and disk while a slow memory leak in a checkout service went unnoticed for six hours, until it OOM-killed the pod at 3am with nobody paged ^[3]. Working backwards, the leak was already underway around 9pm ^[5]. Static thresholds catch cliffs, not gradual drift ^[4].

The statistical path is cheap and dull. You extract numeric features per one-minute window - error_count, p95_duration, unique_error_types - and score them with an unsupervised model such as scikit-learn's IsolationForest, with PyOD wrapping a dozen alternatives, Prophet for univariate trend and seasonality, or Elastic ML if you already live in Kibana ^[6]. Scoring is sub-second, it runs on a $20/month CPU box, each alert is explainable through feature importance, and nothing leaves your network ^[7]. The bill for that is manual feature engineering and a pipeline that breaks silently when a deploy changes your log schema ^[8]. Prophet is univariate only; feed it correlated multi-service metrics and it returns a confident wrong forecast without raising an error ^[9]. And the models drift: he retrains weekly at minimum, treats contamination='auto' as far too conservative for log data, tunes it to 0.01-0.05 and revisits monthly, because the alternative is a false-positive rate that climbs until on-call mutes the channel ^[10].

The LLM path removes the feature engineering entirely. You hand a chunk of logs to the model and it will read semantic context a feature vector cannot, distinguishing a DB connection pool exhaustion pattern from a network timeout, and writing a postmortem summary a human will actually read ^[11]. That makes it a reasonable triage tool where a person is downstream of the output anyway ^[20]. Then the arithmetic arrives. At roughly $0.15 per 1M input tokens for GPT-4o-mini, pushing 50GB/day of raw logs costs $300-600/month in tokens before catching anything ^[12]. That is $6 to $12 per GB/day per month ^[13], or 15 to 30 times the $20 box doing the statistical version ^[14]. Latency closes the other door: 2-5 seconds per request is unusable for sub-second paging on a streaming pipeline ^[15]. Root-cause attribution can also hallucinate and name the wrong service with confidence ^[16].

The third constraint is the one that cannot be fixed later. Logs are full of API keys, session tokens and PII in stack traces, so shipping raw logs to a third-party API without a redaction step - regex or something like Presidio - is a compliance incident in waiting ^[17]. He reports having seen a staging log leak an AWS secret key into a support ticket ^[18]. His framing is that retrofitting compliance after six months of logs have already gone to GPT-4o is the much worse Tuesday ^[19].

Worth watching: whether your own token volume matches his 50GB/day assumption, since the cost case turns entirely on that and on one price point ^[12]; and whether anyone in your org owns the retraining cadence, because an unretrained detector fails in the same way a muted channel does ^[10].