Observability · Illustrative simulators
Predictive monitoring, without the hype
Three levels · When does the alert fire? · How wide should the band be? · Limits · What makes it work · Check · Sources
Most of what gets called predictive analytics in IT operations isn’t magic. A lot of it is arithmetic on data you already collect. The rest is statistics, and only the last step is genuinely probabilistic. Here is the difference, and how to use each one.
Is your operation reactive or proactive?
Most teams still hear about problems from users. Find out where you stand in two minutes.
Take the posture check →The quotes and sources could not be loaded. Please reload the page.
Three levels of prediction
Trend projection
If a disk grows at a steady rate, the time until it reaches a threshold is a calculation, not a guess. Alert on time-to-threshold (‘full in under 24 hours’) instead of on a fixed percentage, and you get a warning while there is still time to act.
Baselines and anomaly detection
Learn what normal looks like for each hour of each weekday, then flag readings that fall outside a band measured in standard deviations. This catches ‘unusual for a Tuesday at 10 a.m.’ even when no fixed limit is crossed.
Where data has both a trend and a daily or weekly rhythm, standard forecasting methods such as triple exponential smoothing (Holt-Winters) account for both.
Patterns learned from history
Some failures have warning signs that only show up in combination: queue depth and memory pressure rising together before the last four outages, for example. Machine learning can spot those patterns, but its output is a likelihood, not a certainty, which is why responsible vendors are careful about calling it prediction.
See it: when does the alert fire?
This simulator needs JavaScript. In words: a disk starting at 55% and growing 1.2% per hour reaches a fixed 90% alert about 8 hours 20 minutes before it is full. An alert on ‘full in under 24 hours’ fires about 24 hours before it is full: 15 hours 40 minutes more warning (illustrative).
Illustrative example. Real growth is rarely perfectly steady; forecasts should use recent history and be recalculated continuously.
Solid line: actual usage. Dashed line: projection from the moment the forecast alert fires. Round marker: forecast alert. Square marker: fixed alert.
Fixed alert fires at:
Forecast alert fires at:
Extra warning time:
Illustrative example. Starting usage is 55%; time to full = (100 − current usage) ÷ growth rate.
See it: how wide should the band be?
This simulator needs JavaScript. It shows seven days of an illustrative response-time metric with three injected incidents, and how many each band width catches.
Illustrative data. Seven days of a response-time metric with a daily rhythm and random noise from a fixed seed, plus three injected incidents. The baseline is the mean and standard deviation for each hour of the day, calculated with the incident hours left out. It is fitted on the same week it is applied to, which flatters the result.
Shaded: baseline band. Round markers: points outside the band. Square markers: points above the fixed limit. A: sharp spike (Wednesday afternoon). B: slow creep over 6 hours (Friday, early morning). C: a normal-looking value at 3 a.m. that is high for 3 a.m. (Saturday).
Baseline band:
Fixed limit:
Narrow bands catch more and cry wolf more. Wide bands stay quiet and miss slow problems. A fixed limit misses the 3 a.m. anomaly entirely. Tuning this trade-off is most of the work.
Illustrative data.
The honest limits
- Sudden failures with no leading signal can’t be forecast; a power loss or a bad change can go from fine to down in seconds.
- A deployment or migration changes what normal looks like; baselines need resetting or they flood you with alerts.
- Forecasts need history: weeks of data at a consistent granularity, kept long enough to see weekly and monthly cycles.
- A prediction nobody owns or acts on is just more noise.
What makes prediction work
- Enough retained history.
- Consistent metric names and units.
- Known capacity limits recorded for each resource. Your CMDB should know them.
- Seasonality handled.
- Change events fed into monitoring so baselines know when something was deployed. From signal to ticket.
- Every forecast alert routed to a named owner.
Where are you? Predictive monitoring check
Eight questions, about two minutes. You get a scorecard with steps to fix each gap. Your answers stay in your browser unless you choose to send a project request.
The check needs JavaScript.
Sources
Facts checked Oct 11, 2026. The simulators use invented numbers to explain the idea; they are not measured data or a benchmark.