Detect

Baselines

A baseline is the range a signal is expected to stay within, learned from that signal's own history. A departure from the baseline fires an alert when it matches the configured direction and persists long enough to count.

How it works#

For rate signals such as error rate, MonitOps compares each new value with the values the same signal took at the same time of day over the previous seven days, by default. The comparison uses the median of that history and its spread, so a few earlier spikes do not widen the expected range.

When a service has less than a day of history, the expected range is learned from the most recent period instead, so detection can start before a full week has accumulated.

Before statistical scoring starts, a signal needs a minimum amount of valid history. Until then the signal is in the insufficient history state, shown in the console. State and event rules on the same entity keep evaluating while a baseline is not yet available.

Kinds of departure#

Kind	Meaning
Sustained	The value stays outside the expected range across consecutive evaluations
Transient	A single evaluation departs by a larger margin than a sustained departure requires
Recurring	The same entity and signal depart repeatedly within a day

The kind is recorded on the alert.

Direction#

Each baseline condition has a direction: upper, lower or both. Only departures in the configured direction are anomalous. A latency signal configured as upper does not alert when latency falls below its expected range.

Missing data and flat series#

Missing data is not zero. An interval with no data is not counted as a low value, so a silent source does not look like a drop in errors or traffic. Silence is detected separately, as its own condition (see Source health).

A flat series, one whose history has no spread, would make any change look infinite. Each signal in the signal catalogue defines a positive minimum scale that is used in place of zero spread, so a tiny change in a constant signal does not alert.

Recovery#

A baseline alert clears after two consecutive valid evaluations that meet the configured recovery threshold. The recovery threshold and the displayed expected band are separate, and the console shows both. No interval with missing data counts toward recovery.

Late data#

When data arrives after an evaluation has run, MonitOps re-evaluates the affected interval and stores the result as a revision. The original decision is kept. The evaluated chart shows the revision beside the decision that was made at the time (see Alarm definitions).

What you see in the console#

On an alert for order-api, the chart shows the expected range as a band, the observed error rate, and the points where the rate left the band. In the sample incident INC-20931, the error rate rises from 0.4 % to 6.8 % at 14:02:11 and leaves its band.

Limits and defaults#

Setting	Default	Notes
History window	Previous seven days, same time of day	Falls back to a recent period when history is short
Direction	Per condition	Upper, lower or both
Recovery	Two consecutive valid evaluations	Missing intervals do not count
Minimum history	Required before scoring	Until met, the signal reports insufficient history

Evaluation of a signal happens when its interval is ready for evaluation, not when each batch of data arrives, so the evaluation rate does not depend on how a sender batches its requests. Each interval has a lateness allowance for data that arrives slightly after it closes.

Failure states#

State	What the console shows
Insufficient history	The signal is marked as having too little history; no baseline alerts are raised for it
Source silent	A separate source-silence alert, not a drop in the signal
Late data	A revision of the evaluation, with the original decision kept

Last updated October 2026