A baseline is a reference model of normal behavior for a metric or service, such as typical latency, throughput or error rate at a given time of day. Monitoring and anomaly detection compare current values with the baseline, so deviations are flagged relative to what is expected rather than against a fixed, manually chosen threshold.
What a baseline is
A baseline answers a deceptively simple question: what does normal look like? For a payment API, normal might be 1,200 requests per second at noon and 150 at 4 a.m., with a p95 latency of around 180 ms during the day. For a batch job, normal might be a spike in CPU every night at 02:00. Once you know what normal looks like, you can judge whether a current value is unusual.
Baselines come in two broad forms. A static baseline is a snapshot, for example the performance of a service measured during a load test or before a migration. It is used for comparisons: is the new version faster or slower than the old one? A dynamic baseline is continuously learned from recent history and updated as behavior changes. It is the foundation of anomaly detection and dynamic thresholds.
How dynamic baselines are calculated
Most dynamic baselines combine three ingredients:
- Level. The typical value, often a rolling median or a mean over a recent window. Medians are more robust against outliers than means.
- Seasonality. Many metrics follow daily and weekly cycles. A good baseline compares Monday 09:00 with previous Mondays at 09:00, not with Sunday night.
- Spread. The expected variation around the level, expressed as a band, for example using standard deviation, median absolute deviation or percentiles of historical values.
More advanced approaches use time-series decomposition, exponential smoothing or machine learning models to forecast the expected value and its confidence band. Regardless of method, an anomaly is a value that leaves the band for long enough to be meaningful.
Baselines per dimension
Baselines are most useful when they are calculated per relevant dimension, for example per service, endpoint, region or customer tier. A global baseline for all endpoints hides the fact that a slow search endpoint and a fast health endpoint have nothing in common. The trade-off is volume: every additional dimension multiplies the number of baselines to learn, which is why high-cardinality attributes such as user IDs are rarely baselined individually.
Why baselines matter
Static thresholds are easy to write and hard to get right. Set them too low, and they fire every day at peak traffic, which is a major driver of alert fatigue. Set them too high, and they miss gradual degradation, such as latency creeping from 120 ms to 280 ms over a week. Baselines adapt to each service and each time of day, so the same rule can cover hundreds of services with very different traffic patterns.
Baselines are also essential for change analysis. Comparing the error rate and latency of a new release with the baseline of the previous version is the core of canary analysis and deployment verification.
Example: weekly seasonality
An illustrative e-commerce checkout service handles about 400 orders per minute on weekday evenings and 80 per minute at night. A static rule "alert if orders per minute drop below 100" would fire every night. A baseline that learns weekly seasonality expects 80 at 03:00 and 400 at 20:00. If orders fall to 220 at 20:00, the value is still well above 100, yet 45% below the expected level, and the baseline flags it as a likely problem, perhaps a broken payment provider.
Best practices
- Baseline the signals that matter: the golden signals of latency, traffic, errors and saturation are a good default.
- Use enough history. Weekly seasonality needs at least a few weeks of data; new services should start with conservative bands.
- Exclude incidents from training windows where possible, so outages do not become the new normal.
- Require duration. A single point outside the band is rarely meaningful; require several minutes of deviation.
- Combine with SLOs. Baselines tell you what is unusual; SLOs tell you what is unacceptable to users. Both are useful.
Common mistakes
A frequent mistake is baselining averages only. An average latency can stay flat while the p99 doubles, so baseline percentiles too. Another is ignoring planned changes: marketing campaigns, holidays and migrations shift normal behavior, and baselines need time to adapt or explicit annotations. Finally, baselines for low-traffic services can be very noisy; aggregating over longer windows or alerting on SLOs instead often works better.
How Obseria helps
Obseria Intelligence learns baselines for metrics, logs and traces automatically, including daily and weekly seasonality, and uses them for anomaly detection without manual threshold tuning. Combined with deployment tracking, deviations are correlated with releases and configuration changes, so you can see whether a shift in behavior started with a specific deployment.