Alert on Surprise, Not Thresholds: Mistral Timestral AI

Every sysadmin I know carries the same three line items in their alert config. Page me if CPU is above 90 percent. Page me if disk latency climbs for five minutes. Page me if the queue depth goes sideways.

We write them once, they fire during every scheduled backup window, every Monday morning login storm, every end-of-month batch run, and we either start ignoring them or we bolt on quiet hours and exclusion rules until the config is a museum of special cases.

Static thresholds have a second, quieter failure mode: they stay silent during real anomalies. A memory leak that grows ten percent per hour never crosses a 90 percent ceiling until it is nearly too late. A disk that fills gradually over a weekend looks completely normal to a five-minute threshold check. A latency curve that doubles at 3 a.m. on a Wednesday, when nothing else on the host is doubling anything, deserves a page precisely because nothing is scheduled. Flat rules cannot see that, because they have no model of what normal looks like at that hour.

The switch: alert on surprise, not on a number

The idea I moved to is simple to say: the alert is not "metric above X", it is "metric far from its own forecast". A forecasting model consumes the recent history of a metric and predicts the next values along with an uncertainty band. If the observation lands inside that band, nothing fires, even if the value is 95 percent of CPU because that is what Tuesday 09:00 always looks like. If the observation lands far outside the band at 3 a.m. on a host that normally idles, that is a page, even though the raw value would never trip a static rule.

The pager gets smarter and quieter at the same time. You stop paying for noise during normal peaks, and you start catching slow drifts and off-schedule weirdness that flat rules were structurally blind to.

Why this was painful before, and is cheap now

Forecasting for alerting is not a new idea. Seasonal baselines, Holt-Winters filters in old RRDtool configs, a Prophet experiment in a side project: sysadmins have tried it for years. The pain was always fit and maintenance. ARIMA-style models are fitted per series, so a fleet of a thousand metrics is a thousand models to keep alive and refit, and none of them transfer. Deep learning forecasters learned more, but they were still typically trained from scratch on each dataset.

What has changed now is the release of Timestral, Mistral's first family of time-series foundation models (October 15, 2026). It applies the pre-training idea that changed text to numbers: one model trained on a huge corpus of series that then forecasts zero-shot on data it has never seen, including domains where its own history is scarce. Per Mistral's announcement:

Four sizes: 5M, 28M, 123M and 209M parameters, all sized to sit on the accuracy-versus-size frontier in their class.
The largest ranks first among pretrained zero-shot models on the field's three main public benchmarks, GIFT-Eval, TIME and fev-bench (vendor benchmark claims, not my measurements).
Output is probabilistic: 21 quantiles per forecast, so you get a whole uncertainty band, not a single number.
It takes multivariate inputs, past-only covariates, and known-future covariates such as schedules and maintenance windows, including categorical ones like machine state, taken directly rather than encoded as numbers.
Inference needs no GPU: on a standard server CPU with 8 threads, a one-day-ahead forecast from three weeks of 15-minute history takes about 10 ms with the 5M model and about 140 ms with the 209M model. Those are vendor-published figures; validate on your own hardware.
Licence is modified MIT, with on-prem, VPC or air-gapped deployment listed, plus a public GitHub repository and a technical report to follow.

That inference number is the one that matters for us. A modest box can continuously forecast your whole metric estate, and paging about a backup-driven CPU peak that the model saw coming becomes a solvable problem rather than an accepted tax.

Why quantiles matter more than the accuracy headline

Benchmark rankings are vendor-audience news. The operational gift is the probability output. A model that emits a full band lets you express your on-call policy in the language it deserves: page me when the observation exceeds the 99th predicted percentile for ten minutes, and open a warning ticket at the 90th. The width of the band is itself signal: an hour where the forecast band suddenly widens everywhere is a host whose behavior the model no longer trusts, which may precede the incident, rather than following it.

With single-value forecasters you end up inventing envelopes by hand. With quantile output, the envelope is a first-class product of the model.

Known-future covariates: the end of the exclusion-rule graveyard

Here is the feature that removes the museum of special cases. Most of our false pages are not random: they are scheduled. The nightly backup, the Saturday index rebuild, the deploy freeze on Friday afternoon, the month-end batch. In the old world you encode each one as an exclusion rule, and the rules drift out of date.

Timestral accepts known-future covariates: things you already know in advance, such as production schedules, maintenance windows, or a planned load increase. You hand it your maintenance calendar and your change schedule, and a load surge the calendar explains is expected rather than flagged as a surprise. The exclusion logic moves from your alert config into the model's input space, where it cannot silently rot.

It also handles categorical covariates directly, day of week or machine state, and multivariate series jointly. A pump's vibration, temperature and pressure do not move independently; likewise a pod's CPU, its request rate and its GC pauses. Forecasting them together lets the model use the dependency instead of alerting on each in isolation.

What I keep the thresholds for

To be honest about the limits: this is augmentation, not replacement.

Keep hard ceilings for saturation risk. If a disk is a gigabyte from full, nobody cares whether that was forecastable. Deterministic guards on irreversible, fatal conditions stay.
A forecast is not root cause analysis. It tells you when and by how much reality deviates from expectation, not why. Pair it with the usual tracing and observability discipline.
Distribution shift applies to your fleet too. When the workload profile changes, an architecture migration, a new traffic mix, a seasonal regime, the relationship between schedule and forecast changes with it. Mistral's path for that is fine-tuning through its Forge pipeline, but even zero-shot deployment deserves a backtest window before you trust it with a pager.
Shadow mode first. Run the model silently alongside the thresholds for a few weeks, record when each would fire, and compare. The savings show up in the shadow report long before you flip any routing.

What the model would look like in the pipeline

No code, just the shape of it: a small scheduler samples your metrics periodically, feeds each series' recent window (with its schedule flags attached as covariates) to the model, and receives a vector of forecasted values plus quantiles. After each observation actually arrives, it lands either inside the predicted band or outside it. Inside: nothing happens. Outside: the deviation is scored, similar historical episodes are pulled for context, and only persistent or large residuals reach the pager. Everything else accumulates into a daily digest you can read with coffee instead of adrenaline.

Mistral frames a bigger version of this for industrial plants, where the forecaster flags an anomaly and an agent retrieves the closest past episodes, drafts a diagnosis from maintenance records and manuals, and hands the operator a plan instead of a beep. The scale is different, but the shape is the one a small fleet can copy: forecast, compare against realization, explain the deviation, page only on the residual humans cannot see in the daily digest.

Verdict

Static threshold alerting answers the question "is this number big?" A forecast-based system answers the better one: "is this number surprising, given everything I already know about this machine?" The first question pages you on Tuesday at 09:00, when nothing is wrong, and stays silent on Wednesday at 03:00, when everything is. The second gets both right, and the model that does it is small enough to run on a CPU per forecast and cheap enough that the answer is essentially free.

FAQ

Does this replace my thresholds entirely?

No. Keep deterministic guards on irreversible, fatal conditions such as near-full disks or failed replicas. What you replace is the broad class of big-number alerts that fire on schedule and miss irregular incidents.

What makes Timestral different from a homegrown Prophet setup?

It is a foundation model, pre-trained on synthetic data, then refined on real data, so it forecasts zero-shot on your series without a per-series fit or refit cycle, and it accepts multivariate and schedule covariates out of the box. A per-series statistical setup is one you fit and maintain yourself.

Is this practical for a homelab?

Yes, that is the point of the small models: the 5M variant reportedly forecasts a day ahead from three weeks of history in about 10 ms on 8 CPU threads, so even per-minute forecasts stay inexpensive. Evaluate on your hardware before wiring it to a pager.

How do I express an alert from a probabilistic forecast?

Pick quantiles. A common pattern: warning at the 90th predicted percentile, page at the 99th with a ten-minute hold, plus a separate signal when the forecast band itself widens, which often precedes an incident.

I Replaced My Alert Thresholds With a Forecasting Model