Tuning thresholds

In this section you will learn how to diagnose a metric reported with the wrong status, and how to adjust it.

Read the applied values first

The threshold pills displayed at the top of the system and process report panels always show the values actually being applied to that metric, whether they come from a fixed setting or from a computed baseline. Comparing those pills with the chart underneath answers most questions on its own.

An infinity symbol in a pill means the threshold is not configured and that level can never be reported. See How thresholds work for the details.

Everything is reported critical or major

A healthy component whose metrics are all coloured is almost always a unit mismatch or a stale fixed value.

Open the report panel and read the threshold pills for the affected metric
Compare the pill values against the metric’s unit in the unit table
If the threshold is far below the normal operating value, it is a fixed value entered in the wrong unit

The classic case is process memory: thresholds of 1 and 3 are megabytes, so every process on the host breaches them. Clearing those fields and letting the auto-threshold learn each process’s normal range resolves it.

A metric turns yellow as soon as the host does anything

A minor threshold very close to zero, such as 0.01 on system cpu, reports minor for any activity at all. Raise the minor threshold to a value that reflects genuinely elevated usage, keeping minor < major < critical.

Nothing ever alerts

Check, in order:

Are the three thresholds empty? An unconfigured metric always reports OK
Is the metric’s monitoring toggle enabled on the agent?
If auto-threshold is enabled, has a baseline been produced yet? A metric with too few samples or no variation keeps its fixed values, and if those are empty it stays OK

Thresholds look far too tight after computing them

A baseline computed shortly after an agent registers describes only the few minutes of history available at that moment. Let the agent collect over a representative period, ideally a full working day, then trigger the compute threshold action again, or simply wait for the nightly run to replace it.

Alerts fire on brief spikes

For process traffic, increase the averaging window so more consecutive samples are averaged before the comparison. A larger window reacts more slowly but ignores isolated spikes.

For the other metrics, widen the gap between the baseline and the alert by increasing the standard deviation factors, or move to a longer lookback window so that the normal daily variation is included in the baseline.

Changing the lookback window

Changing the auto threshold range does not rewrite existing baselines on its own. The new window is applied at the next nightly run, or immediately if you trigger the compute threshold action.

Note:

Widening the lookback window only helps if the agent has actually been collecting for that long. Selecting a window of 8 weeks on an agent installed three days ago produces a baseline built from three days of data.