Knowledge Base

Baselines & Dynamic Thresholds: A Practical Setup Guide and Workflow Walkthrough

Why this matters Right now, most alert thresholds in SQL DM are static — one fixed number, all day, every day. The problem: “normal” doesn’t...

Written By: Brandon Adams
Last Updated: August 11, 2026
9 minutes read

Why this matters

Right now, most alert thresholds in SQL DM are static — one fixed number, all day, every day. The problem: “normal” doesn’t look the same at 2pm on a Tuesday as it does at 2am during a batch job. A CPU threshold tight enough to catch a real problem during business hours is usually too loose to catch one overnight — and a threshold loose enough for peak load will fire constantly during quiet periods.

Baselines solve this by having SQL DM learn what normal actually looks like for each instance, based on its own collected history (mean, standard deviation, min/max). Dynamic thresholds then use that baseline instead of a fixed number — alerting on a percentage deviation from expected behavior rather than a flat value.

Use this when:

You’re getting alert fatigue from static thresholds that are too sensitive during off-peak hours or too loose during peak hours
The instance has distinct activity windows (business hours vs. overnight ETL/batch, weekday vs. weekend)
You want SQL DM to recommend sane threshold values instead of guessing at fixed numbers yourself

Before you set one up

Permissions: You need the Modify privilege on the instance. View-only users can see the Baseline Configuration window but can’t change it.
Pick the right baseline type:
- Dynamic — a rolling 7-day window of collected data. Good default; it self-updates as behavior changes.
- Custom — a fixed date range that doesn’t move. Use this if you want to lock in a known “healthy” period (e.g., before a workload changed) rather than let it drift.
Be deliberate about which days/times feed the baseline. If the instance is idle nights and weekends, leave those out of the calculation — including dead time will drag the baseline down and make daytime thresholds too sensitive.
Consider multiple baselines per instance if it has more than one distinct activity pattern (e.g., business hours, evening batch jobs, overnight ETL). Use the Baseline Visualizer first to spot where those windows actually are before you define them.
Multi-instance rollout: once you’ve dialed in a baseline configuration on one instance, you can push it to others rather than repeating the setup — useful for instances with similar workload shapes.

Step-by-step setup

1. Open Baseline Configuration

Right-click the monitored SQL Server instance in the Servers pane and select Baseline Configuration (this opens the Baseline Configuration tab of the Monitored SQL Server Properties window).

2. Choose the baseline period

Select Dynamic for a self-updating 7-day rolling baseline, or Custom to lock in a specific date range.

3. Select the days and times to include

Use the day/time picker to define the window the baseline should be calculated from. Clear out days/times when the server isn’t representative of normal load (maintenance windows, known-idle periods) so the baseline stays accurate.

4. (Optional) Add multiple baselines

Click Manage Baseline to add and schedule additional baseline periods beyond the default — e.g., one for business hours and a separate one for overnight batch activity.

5. (Optional) Apply the configuration to other instances

Click Apply Baseline Configuration, move the target instances from Available Servers to Added Servers, and click OK. Note: in the Change Log, this shows up as one log entry per affected instance, not one entry total.

Select Monitored SQL Server Instances dialog — source: Configure server baseline options

6. Turn on dynamic thresholds for specific alerts

In Configure Alerts, select the metric you want to alert on dynamically (e.g., SQL Server CPU Usage %). Instead of (or alongside) the static warning/critical thresholds, enable the baseline-based threshold and set it as a percentage of the baseline — e.g., 100% means “alert when current value matches or exceeds the baseline value for this time of day,” 120% means “alert only when 20% above expected.” This is what makes the threshold move with the time of day instead of sitting at one fixed number.

7. Let SQL DM recommend thresholds for you

Once enough collections have run against the baseline, SQL DM will surface a prompt at the top of the Alert Configuration window: “Alert recommendations are available for this SQL Server.” Click it to open Alert Recommendations, review the suggested warning/critical values (calculated as a set percentage over the standard deviation — adjustable via the Options button), check Apply for the ones you agree with, and click OK.

Alert Recommendations window — source: View suggested alert thresholds

To change the percentage-over-standard-deviation used for the recommendations, click Options at the bottom of the window:

Alert recommendation options dialog — source: View suggested alert thresholds

8. Confirm it’s working

Check the metric graphs on the Resources tab — with baseline enabled, they’ll overlay the baseline curve against actual values so you can visually confirm the threshold is tracking expected behavior rather than sitting flat.

Source: SQL Diagnostic Manager 14.1 Product Documentation — “Configure server baseline options” and “View suggested alert thresholds.”

Note: the screenshots above load live from wiki.idera.com — they’ll display correctly for anyone with access to the Idera wiki, but won’t render if opened somewhere without a connection to that site.

Brandon Adams

SQL Server Tools Product Marketing Manager

With over two decades of experience in SQL, SaaS, data center infrastructure, power quality, data storage, disaster recovery, and IT security, Brandon bridges technical expertise...