Dashboard is the high-level monitoring screen for CPU, memory, workload, IO, and TempDB conditions on the connected SQL Server instance. It is designed for fast triage, so if a metric looks abnormal, the next step is usually to open the relevant deeper module.
- Whether the host or SQL Server process is under CPU pressure.
- Whether memory, buffer pool, or TempDB conditions are deteriorating.
- Whether workload volume or compile activity has shifted.
- Whether storage latency is becoming a bottleneck.
- Batch/sec, Transactions/sec, Compilations/sec, and Recomp/sec are rate metrics averaged over the last refresh interval.
- The first refresh can temporarily show 0 for rate-based counters until a prior sample exists.
- The page is for fast monitoring, not full root-cause analysis.
These metrics tell you whether the host and SQL Server are under CPU or session pressure.
Shows total operating system CPU utilization. Use it to see whether the host itself is CPU-bound, including pressure from non-SQL processes.
Below 70 is normal, 70-89 is warning, and 90 or higher is bad.
Shows CPU utilization for the SQL Server process. If this is high, CPU-heavy queries, parallelism, or compile and recompile activity may be contributing.
Below 70 is normal, 70-89 is warning, and 90 or higher is bad.
Counts currently active user sessions. Sudden increases can indicate connection storms, long-running requests, or pooling issues.
Below 50 is normal, 50-99 is warning, and 100 or more is bad.
Shows CPU scheduler pressure. When tasks are ready to run but cannot get CPU time, this value rises and becomes a strong CPU bottleneck signal.
Below 5 is good, 5-19 is warning, and 20 or more is bad.
These metrics show buffer pool pressure, memory demand, and cache efficiency.
Shows how much memory SQL Server has currently committed for its memory manager. In a steady state it usually approaches Target Memory.
A Total/Target ratio of 0.90 or higher is good, 0.75-0.89 is warning, and below 0.75 is bad.
Shows how much memory SQL Server wants to use under current conditions. It should be interpreted together with Total Memory rather than alone.
There is no separate built-in alert threshold for this metric in the current UI.
Page Life Expectancy estimates how long a data page stays in the buffer pool. Sharp drops can indicate buffer churn or memory pressure.
Above 300 is good, 61-300 is warning, and 60 or lower is bad.
Shows how often reads are served from memory instead of disk. Trend is usually more meaningful than a single snapshot.
Above 95 is good, 91-95 is warning, and 90 or lower is bad.
These metrics describe throughput, transaction activity, and compile behavior over the last refresh interval.
A high-level throughput signal that reflects how many batches SQL Server is processing. Spikes often correlate with higher CPU and IO demand.
There is no built-in alert threshold for this metric in the current UI.
Shows transactional throughput. Comparing it with Batch/sec helps distinguish request volume from true transaction activity.
There is no built-in alert threshold for this metric in the current UI.
Shows how often SQL Server is compiling plans. High values relative to Batch/sec can indicate ad hoc workloads, weak parameterization, or plan cache churn.
Below 1000 is normal, 1000-4999 is warning, and 5000 or more is bad.
Shows how often plans are being recompiled. Sustained increases can add CPU overhead and point to plan stability issues.
0 is good, 1-99 is warning, and 100 or more is bad.
These metrics show storage latency and pending IO pressure.
Shows average read latency in milliseconds. High values can indicate storage pressure or read-heavy random IO patterns.
Below 5 ms is good, 5-19 ms is warning, and 20 ms or higher is bad.
Shows average write latency in milliseconds. Sustained increases can affect checkpoint activity, TempDB behavior, and overall throughput.
Below 5 ms is good, 5-19 ms is warning, and 20 ms or higher is bad.
Shows write latency for transaction log files only. This is especially important when commit latency or WRITELOG waits are suspected.
Below 5 ms is good, 5-19 ms is warning, and 20 ms or higher is bad.
A best-effort proxy for pending IO requests. Sustained higher values suggest that the storage layer is falling behind demand.
Below 2 is good, 2-9 is warning, and 10 or more is bad.
These metrics show TempDB space pressure, log growth, and allocation contention.
Shows the percentage of TempDB data file space currently in use. High values may be caused by temp tables, spills, version store growth, or large index operations.
Below 50 is good, 50-79 is warning, and 80 or higher is bad.
Shows TempDB transaction log utilization. Rapid growth can point to long-running transactions or heavy version store activity.
Below 50 is good, 50-79 is warning, and 80 or higher is bad.
A TempDB allocation contention signal. Non-zero values suggest waits on TempDB allocation bitmap pages.
0 is good, 1-9 is warning, and 10 or more is bad.
- If CPU % is high but SQL CPU % is low, pressure is more likely coming from a non-SQL process.
- If SQL CPU % and Runnable Queue are both high, CPU pressure inside SQL Server is more likely to be real.
- If Total Memory, PLE, and Buffer Hit Ratio all deteriorate together, investigate buffer pool pressure.
- If Compilations/sec or Recomp/sec rises, review plan cache behavior and query design.
- If IO read, write, log latency, and disk queue are elevated together, storage latency is a likely factor.
- If TempDB Usage, TempDB Log Used, and PFS/GAM Waits rise together, review TempDB sizing, file layout, and spill-heavy workloads.
- Open Dashboard first to check the current operating picture.
- Compare abnormal metrics across CPU, memory, IO, workload, and TempDB instead of reading one metric alone.
- Use the quick interpretation guide to decide which subsystem looks most suspicious.
- Jump into Query Statistics, Wait Statistics, Blocking Analysis, or another module for deeper analysis.
- Read-only monitoring with no automatic remediation.
- Designed to guide investigation, not apply changes.
- Best used as the starting point before drilling into a specialized module.