Dashboard is an on-demand health snapshot for CPU, memory, workload, IO, and TempDB conditions on the active SQL Server connection. It is designed for rapid interactive triage: refresh the current evidence, identify a pressure area, then move to a deeper module for investigation. It does not collect data while the desktop application is closed.
- 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.
- Not a query-level tuning screen.
- Not a blocking chain analysis screen.
- Not a replacement for wait analysis or plan review.
- Not a 24/7 collector, SLA dashboard, or centralized operations console.
- Not an automatic remediation tool.
The screen groups live instance health into five blocks: Server Health, Memory Health, Workload, IO, and TempDB. This layout is meant to help the operator correlate pressure signals instead of reacting to one number in isolation.
- Use refresh cycles to watch direction, not just one snapshot.
- Start with the most visibly degraded section, then validate with adjacent metrics.
- Use status colors as guidance, not as the final diagnosis.
These signals tell you whether the host or the SQL Server process is under CPU or concurrency 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, expensive queries, compile activity, or parallelism 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 workload spikes.
Below 50 is normal, 50-99 is warning, and 100 or more is bad.
Shows CPU scheduler pressure. If tasks are ready to run but cannot get CPU time, this value rises and becomes a strong bottleneck signal.
Below 5 is good, 5-19 is warning, and 20 or more is bad.
These metrics show memory demand, buffer pool behavior, 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. Interpret it together with Total Memory instead of by itself.
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 memory. 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. The 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 and compile behavior over the current refresh interval.
A high-level throughput signal showing 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 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 access 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 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 matters 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 storage 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 in use. High values may be caused by spills, temp tables, version store growth, or large index work.
Below 50 is good, 50-79 is warning, and 80 or higher is bad.
Shows TempDB log utilization. Rapid growth can point to long-running transactions or heavy version store activity.
Below 15 is good, 15-29 is warning, and 30 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 on the host.
- If SQL CPU % and Runnable Queue are both high, SQL Server CPU pressure is more likely to be real.
- If Total Memory, PLE, and Buffer Hit Ratio all deteriorate together, investigate memory pressure first.
- If Compilations/sec or Recomp/sec rises sharply, 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 after connecting to confirm the current operating picture.
- Compare abnormal metrics across CPU, memory, workload, IO, and TempDB instead of reading one metric in isolation.
- Use the combined pattern to decide whether the likely problem area is CPU, memory, storage, TempDB, or workload shape.
- Then move to Query Statistics, Wait Statistics, Blocking Analysis, Object Explorer, or another deeper module.
- Batch/sec, Transactions/sec, Compilations/sec, and Recomp/sec are rate metrics averaged over the current refresh interval.
- The first refresh can temporarily show 0 for rate-based counters until a prior baseline sample exists.
- When the active connection changes, the app resets rate baselines so counters from different servers are not mixed together.
- Dashboard is read-only and does not apply any remediation.
- Dashboard is designed for fast triage, not full root-cause analysis.
- Some signals depend on SQL Server visibility and can be partial if permissions are limited.
- Rate-based counters are more meaningful after the second refresh onward.
- Use trend and correlation across sections rather than treating one metric as conclusive on its own.