Skip to content

What Is Runtime Baselining?

Runtime baselining records normal SQL Server execution times so teams can detect meaningful changes in queries, procedures, and jobs.

Runtime baselining establishes what normal execution looks like for a SQL Server workload. It gives a slow-job or slow-query alert a meaningful point of comparison.

Definition

A baseline is a summary of previous executions for the same work under comparable conditions. It may include typical duration, a range of durations, execution count, and the time or workload pattern those measurements came from.

Building a useful baseline

  • Group runs by query, procedure, or job rather than mixing unrelated work.
  • Keep weekday, weekend, peak, and maintenance periods distinct when they behave differently.
  • Record enough history to show normal variation, including percentiles and outliers.
  • Revisit the baseline after a planned workload, schema, or infrastructure change.

Operational example

A nightly job usually takes between 10 and 15 minutes, but runs twice as long on month-end processing days. A baseline that separates those days avoids a false alarm while still flagging a 40-minute ordinary run.

Common pitfalls

An old baseline can turn expected growth into constant alerts. A rolling baseline can have the opposite problem: it may gradually absorb a real regression. Review changes against a known stable period before updating the reference.

SQL Cockpit context

SQL Cockpit uses runtime history to help teams compare current activity with previous behaviour and decide which changes deserve investigation.

FAQ

Is one average runtime enough?

Usually not. A range or percentile shows how variable the work normally is.

When should a baseline be reset?

Review it after a deliberate change, but keep the earlier period available for comparison.

Suggested Related Articles