One prompt. Twelve lines. A working SQL Server Wait Statistics dashboard with live charts, auto-refresh, dark theme, recommendations panel. I did not plan to write this post. But I could not stop thinking about what happened.
Let Me Tell You What I Actually Needed
I wasn’t trying to do anything particularly impressive when I started this. I just needed to see what was happening inside a SQL Server, right now, without the usual drama of setting up a full monitoring stack.
I didn’t want Grafana or Datadog. I didn’t want agents to install, a new license to justify, or a whole weekend to sacrifice just to get some visibility. I just wanted a clean look at my wait stats in a browser. That was the whole requirement.
So I described it in plain English. Twelve lines of text. I gave those lines to Claude Code and this dashboard is what came back. It is dark-themed, auto-refreshing, and reads live from sys.dm_os_wait_stats and sys.dm_exec_requests. The best part is that it’s built entirely in HTML and JavaScript with no external tools or middleware sitting behind it.
What It Does
The dashboard connects directly to two DMVs. sys.dm_os_wait_stats gives the cumulative picture since the last server restart. sys.dm_exec_requests shows what is actively waiting right now. No middleware. No agent. Just those two views and some JavaScript doing the work.
Here is what it covers:
- Categorises every wait type into CPU, I/O, Memory, or Other
- Shows cumulative wait time since the last server restart
- Lists top wait types by total wait time
- Shows average wait time per task
- Shows active waits happening at this exact moment
- Charts for wait distribution across all categories
- Breaks down signal wait versus resource wait
- Recommendations panel based on what the server is actually doing
- Auto-refreshes every few seconds
- Highlights CPU pressure when signal wait crosses 25%
The signal wait versus resource wait split is honestly the most important thing here. Signal wait is how long a thread sat waiting just to get back on the CPU after it was already ready to run. That has nothing to do with your disk. Nothing to do with memory. That is purely CPU pressure. When that crosses 25% of total wait time, you have a specific problem, and this dashboard will tell you clearly.
The recommendations panel at the bottom is not generic. It reads what is actually happening and gives you something practical. The kind of thing a DBA would say after looking at the numbers, not after reading a checklist.
The Exact Prompt
I want to be honest about this. I did not write clever prompt engineering. I just wrote what I wanted.
Create a SQL Server wait statistics analysis dashboard. Use sys.dm_os_wait_stats and sys.dm_exec_requests. Requirements: - Categorize waits into CPU, I/O, Memory and Other - Show cumulative wait time since last restart - Display top wait types - Show average wait time per task - Show active waits - Charts for wait distribution - Signal vs resource waits - Recommendations based on patterns - Modern dark themed dashboard - Auto refresh every few seconds - Highlight CPU pressure if signal wait exceeds 25%
That is it. Claude Code took that, figured out the right DMVs, categorised the wait types correctly, filtered out the benign ones, wrote the delta logic for the refresh, built the charts, wired the recommendation engine, and produced the full CSS. One pass. The screenshot above is what came out.
Why I Was Building This
This isn’t just a hobby project; I am actually building this as a Proof of Concept for an organization I am helping. I will deliver this first version, and then their internal team will take it over and adapt it for their own environment. My role eventually shifts into mentoring and guiding them as they build it out further.
Interestingly, this is the second time in the last month that a project has followed this exact pattern. An expert comes in, uses AI to compress weeks of work into a few days, delivers a working foundation, and then moves into a teaching role. It is starting to feel like a new standard for how technical consulting is going to work from now on.
Some honest reflections
I want to be honest about this part as well.
I have been doing this work for more than twenty years, so I know very well what it normally takes to build what you see in that screenshot. Just the query part alone is a heavy lift. You have to get the categorization right, decide which waits to ignore, and make sure the refresh is actually showing rates instead of just raw totals. That alone is a solid afternoon of work for someone who really knows these DMVs. This isn’t a task for a junior person; it is for someone who has lived inside this data for years.
Then you have to add the UI. You need a refresh loop that does not abuse the server, the threshold logic for alerting, and a recommendation engine that actually says something useful instead of something obvious. That is easily another half day of effort.
I have built different versions of this many times across many different projects. So when I watched something like this come out of just twelve lines of plain English, I did not feel proud. I did not feel excited in the usual way. I felt something I still have not fully named. It was something quiet and a little unsettling.
The bottleneck was never just the code. It was always knowing what to ask for. That gap has now become very small.
And here is what keeps coming back to me. I knew what to ask for because I have spent years doing this the hard way. I know what signal wait means because I have watched it climb during real incidents, at night, when the pressure was on. I knew what it meant before I even finished reading the number.
I know why 25% is the right threshold because I have seen both sides of it enough times that it stopped being a number and became a feeling.
The prompt was twelve lines. What was behind the prompt was twenty years.
The Thing Nobody Wants to Say Directly
There is a comfortable version of this story where AI just helps people build faster, barriers come down, and more people can create useful things. All of that is true. But sit with this for a moment.
The junior developer who spent three years building things slowly and getting them badly wrong was not wasting time. Every execution plan that left them confused, every dashboard they built that answered the wrong question, and every 4 AM incident where they guessed wrong three times before finally getting it right was depositing something into them. It is something very difficult to name but very easy to feel when you are in a room with someone who has it and someone who does not.
That slow, painful, and sometimes humiliating process is now being compressed.
The honest question, the one that nobody at a conference will ask out loud, is whether compressed experience produces the same thing as slow experience. We have to wonder if it produces something that looks exactly the same until the moment everything is on fire and it suddenly does not.
I am not saying one is better than the other, but they are certainly different. That difference will show up at the worst possible time: when the dashboard looks fine, the query looks correct, the wait stats look normal, and yet the system is still struggling. That moment is coming for everyone, and the person you want in the room at that moment is very specific.
What This Actually Means If You Are a SQL Server Professional
If you are a junior or mid-level data pro, the “grunt work” of the job is basically changing overnight. The hours spent writing standard monitoring queries, building routine dashboards, or setting up basic alerting are going to be compressed into minutes. That part is moving faster now, and there is no going back.
But there is a core part of this job that isn’t going anywhere: the intuition. AI can build the instrument, but you still need someone in the room who actually knows how to read the gauges. Knowing which DMV to point at for a specific symptom is one thing, but understanding that CXPACKET by itself tells you nothing without checking your MAXDOP settings and the actual query plans is another. It is that split-second judgment to look at an automated recommendation and know if it actually fits your workload or if it is just generic advice that might actually tank your server performance.
That kind of “knowing” does not come from generating tools quickly. It comes from years of watching those tools give you the wrong readings and learning exactly when to trust the dashboard and when to ignore it and dig deeper.
The dashboard came together in minutes. What it takes to understand what the dashboard is actually telling you, that still takes years.
The one thing that has not changed in all of this is that your server is waiting on something right this second. There is critical information sitting inside sys.dm_os_wait_stats right now that you probably have not looked at this week, or maybe even this month, mostly because setting up that kind of visibility always felt like a massive chore.
Well, that excuse is officially gone. The prompt is in the blog post. Go run it, get the dashboard up, and then actually take the time to sit with what the numbers are telling you. That is the one part of the job I cannot put into a prompt for you.
Reference: Pinal Dave (https://blog.sqlauthority.com/), X
