DarlingData: SQL Server troubleshooting scripts that read the instance instead of your dashboard

The gap DarlingData targets: a live instance with no monitoring around it

The stated audience is narrow and worth repeating in its own terms: someone who needs to troubleshoot SQL Server performance now, and does not want to spend that time learning DMVs, Extended Events, XML, or the SSMS interfaces that expose them. That is a real gap. Most monitoring tooling assumes a deployment pipeline, an agent, and days of collected data before it says anything useful. DarlingData takes the opposite position and interrogates the instance directly at the moment of the incident.

The project is not a single tool but a directory of standalone stored procedures, each with its own folder at the top level of the repository, including sp_PressureDetector, sp_PerfCheck, sp_HumanEvents, sp_HumanEventsBlockViewer, sp_QuickieStore, sp_QuickieCache, sp_QueryReproBuilder, sp_HealthParser, sp_LogHunter, sp_IndexCleanup, and sp_QueryStoreCleanup. Alongside them sit more specialised folders such as Alerts, Clear Token Perm, Dynamic SQL Logging, Export-SqlResults, Helper Views, Ola Stats Only Job, ProtectSession, and SQL Debug Example.

That scope matters, because it defines what you get: an on demand diagnostic toolkit rather than a daemon, a scheduler, or a dashboard. The project states plainly that the scripts are not a replacement for a mature monitoring tool, but that they do capture important issues and report on existing diagnostic data. That framing is the honest version of the pitch, and it is the right lens for evaluating the whole repository.

sp_PressureDetector: parameters that decide what you see

sp_PressureDetector is the entry point most people meet first, aimed at the case where queries are timing out, dragging, or driving CPU to the roof. It reports wait stats since startup, database file size and stall, tempdb configuration, memory consumers and allocation, low memory indicators, current query memory grants, CPU configuration with retained utilisation, thread count and current usage, any current THREADPOOL waits, and the queries running right now. The README notes that THREADPOOL waits are best observed with the Dedicated Administrator Connection.

What the script reports is only half the story. What it decides to report is controlled by parameters, and the defaults are opinionated. @what_to_check accepts "all", "cpu", and "memory", defaulting to all. @cpu_utilization_threshold defaults to 50 and sets the lower bound for reporting high CPU utilisation, while @minimum_disk_latency_ms defaults to 100 as the low bound for reporting disk latency. Two bit parameters, @skip_queries and @skip_plan_xml, both default to 0, so the first run pulls running query details and plan XML whether or not you need them. @skip_waits turns off the wait collection for repeat runs.

Those defaults will not suit every estate. A server whose normal disk latency sits above 100ms will report it as a finding on every execution, and the plan XML fetch is the expensive part of the script. Read the parameter table in the README before running this against a production box during an incident, because the noise floor is set by those defaults.

QuickieStore and QueryReproBuilder: turning stored history into a script you can run

Query Store is where most SQL Server performance work starts, because it keeps the plan history that an investigation usually needs. sp_QuickieStore is described in the project navigation as the fastest and most configurable way to navigate Query Store data, which is a positioning claim about workflow rather than about query speed: the point is to get from a pile of captured queries to a narrow list quickly.

sp_QueryReproBuilder sits directly downstream of that idea. It generates executable reproduction scripts from Query Store data. That is a distinctive capability, because it converts a historical record into something you can re-run against a test server and observe directly, rather than reading a plan XML file and reconstructing intent by hand. The repository also contains a SQL Debug Example folder, and a folder named Create Long IN List, which suggests the author's habit of encoding repeatable diagnostic patterns as reusable TSQL rather than as one off queries.

The cleanup side is covered too. sp_QueryStoreCleanup removes duplicate and noisy queries from Query Store, which matters because noise in that store is a plausible cause of the slow navigation that makes people reach for other tools in the first place. The naming convention of these procedures is consistent throughout the repository, so anything you write against them will read the same way. Note that these scripts act on live Query Store data, so run the cleanup procedure against a copy first rather than discovering its behaviour on production history.

Extended Events work: sp_HumanEvents, the block viewer, and the health parser

The scripts that need history use Extended Events, which is where the complexity usually lives for database administrators. sp_HumanEvents is described as a way to use Extended Events to track down various query performance issues, and sp_HumanEventsBlockViewer exists to analyse the blocked process report once one exists. The pairing is deliberate: the first script produces the artifact, the second turns it into something readable without asking anyone to parse XML by hand.

sp_HealthParser takes a different angle and pulls all the performance related data from the system health Extended Event, which is already running on most instances by default. That means the diagnosis can start with data that already exists on the server, which is exactly the position the project takes when it says the scripts report on existing diagnostic data. Nothing needs to have been switched on in advance.

The trade-off is that the project does not pretend this replaces instrumentation. Capturing events continuously across a fleet, retaining them, and alarming on them is a different job from parsing a report that was just produced. For a single incident on a server nobody has instrumented, this is a shortcut to a usable answer. For a recurring problem across forty servers, you would still be building the monitoring layer that the project says these scripts are not a replacement for. The blocked process report in particular is only as good as the session configuration that captured it, and the README does not document a rollback path or a retention policy for the collected events.

Index and plan cache hygiene: sp_IndexCleanup and sp_QuickieCache

Index work gets two dedicated scripts, and the naming reflects the approach. sp_IndexCleanup identifies unused and duplicate indexes, which is a diagnostic rather than a destructive operation. sp_QuickieCache describes itself as high-impact query detection from the plan cache using Pareto analysis. Pareto analysis on plan cache usage means concentrating on the small number of queries responsible for most of the resource cost, which is a sharper method than ranking everything by total logical reads, because a hundred queries each costing a little can look worse on a top list while costing less in total.

These two scripts cover different layers of the same question. sp_IndexCleanup looks at what the index structures are doing, including which ones carry no weight at all. sp_QuickieCache looks at what is actually running and identifies the queries with the largest footprint. Used together they answer a common operational question: whether a poorly chosen set of indexes is forcing expensive plans to execute more often than necessary.

The caution is the same one that applies to every part of the repository, and it is worth being blunt about it. Identification is safe and actionable. Removal is a separate decision, and the repository includes folders such as Ola Stats Only Job for scheduling a job and TestBackupPerformance for checking backup behaviour before you touch recovery paths. Nothing in the repository description says the cleanup scripts will tell you which unused index is safe to drop in your particular workload, because that question depends on the reporting window, the workload shape, and how often each index was needed in the past. Read the output as a shortlist for testing, not as an approved change list.

Where the scripts stop: live inspection, no continuous history

The clearest limitation is structural rather than a bug. Every script here is something a person runs. The outputs are grids in your SQL client, and the evidence they produce lives wherever you put it. There is no agent, no alert, and no trend store inside the repository, and the project says so directly when it describes itself as not a replacement for a mature monitoring tool.

Two narrower gaps follow from that. First, the coverage is instance-local. sp_PressureDetector can tell you what is happening on one server right now, which is exactly what you want at 2am for the server that is on fire and exactly what you do not want when the question is whether the pattern has been growing for three months. Second, support is routed entirely through GitHub, and the project asks for patience because a single person answers questions, fixes bugs, and adds features. That is a healthy sign for a personal project and a weak foundation for a dependency in an on call rotation.

Compatibility is another limit with a clear edge. The scripts are only guaranteed to work on Microsoft supported SQL Server versions, with the stated reason that older releases either miss too much information or lack the features the scripts depend on, naming Extended Events and Query Store directly. If your estate includes an out of support version, that is where the toolkit stops being dependable, and no configuration flag will change it. The Pressure Detector parameters also assume sensible defaults for disk latency and CPU utilisation, and those two numbers are the ones to tune first.

Licence, release cadence, and what an adoption decision looks like

The repository carries the MIT licence, which is permissive for internal use and modification and keeps the obligations narrow, though the licence text itself is the thing to read rather than this summary. There is a LICENSE.md at the repository root and a CONTRIBUTING.md alongside it, and the project is hosted at erikdarlingdata/DarlingData with the default branch main. The homepage listed for the project is https://www.erikdarling.com/.

On maintenance, the facts are concrete rather than impressionistic. The last push was on 2026-10-20, and recent releases are dated and named, including Updates_20261001 tagged as The Nightmare Before Compaction on 2026-09-29, Updates_20260901 tagged as Permission to Come Aboard on 2026-08-31, and a rolling dev-latest build from 2026-08-28. The monthly naming pattern means that taking a release means taking a snapshot of scripts at a point in time, and you should record which one you deployed rather than assuming main stays put.

There is also visible CI, through a workflow file named sql-tests.yml, which is a reasonable signal for TSQL that the scripts are exercised rather than merely written. The practical adoption picture is that you clone, run one script inside your existing change window, and read the grid. Verify the SQL Server version sits within the supported range, adjust the CPU and disk thresholds, and confirm the login has the permissions the procedure expects before the incident rather than during it.

Editorial conclusion

DarlingData fits DBAs and developers who need an answer about a live SQL Server instance now, particularly when no monitoring stack is in place, and it is a poor fit for teams that need continuous collection, alerting, or long term trend storage. Before adopting it, confirm the script runs on your supported SQL Server version, review the parameter defaults against your own thresholds, and check that the accounts you use hold the permissions each script needs, since the project handles support on GitHub and states that older versions are missing too much information.

Frequently asked questions

Official sources

1. erikdarlingdata/DarlingData on GitHub
2. License: MIT
3. Project website
4. README
5. Releases