SQL Server First Responder Kit: sp_Blitz and the Scripts That Answer 3AM

A kit of scripts for the moment things are already broken

The README opens with a deliberately unsentimental line: "You're a DBA, sysadmin, or developer who manages Microsoft SQL Servers. It's your fault if they're down or slow." That framing explains the shape of the whole repository. The SQL Server First Responder Kit is not a monitoring agent, not a dashboard, and not a service you register somewhere. It is a folder of T-SQL stored procedures that you install into a database and then run when you need an answer.

That design has consequences worth sitting with before anything else. Nothing runs on a schedule unless you build that schedule yourself. Nothing phones home. Nothing stores your query text on someone else's server. The cost is that you have to remember to run the thing, or wire the health check into your own automation. The benefit is that when the pager goes off at three in the morning, the diagnosis tool is a stored procedure in the same instance that is having the bad morning, and it already has permission to read the DMVs.

The project sits at roughly 3,900 stars and 1,100 forks, which is a lot of adoption for a folder of scripts. It has only two open issues at the moment of writing, and the default branch is named `dev` rather than `main`, a small sign that the scripts are treated as something continuously edited rather than a periodically versioned release.

The repository description names the core members: "sp_Blitz, sp_BlitzCache, sp_BlitzFirst, sp_BlitzIndex, and other SQL Server scripts for health checks and performance tuning." Read that as a menu of emergency tools, and the rest of the article makes more sense.

What is actually in the folder

The repository tree is short and legible. At the top level sit the individual procedures, each in its own file: `sp_Blitz.sql`, `sp_BlitzAnalysis.sql`, `sp_BlitzBackups.sql`, `sp_BlitzCache.sql`, `sp_BlitzFirst.sql`, `sp_BlitzIndex.sql`, `sp_BlitzLock.sql`, `sp_BlitzWho.sql`, `sp_DatabaseRestore.sql`, `sp_ineachdb.sql`, and `sp_kill.sql`. Alongside them are the installer files, `Install-All-Scripts.sql` and `Install-Azure.sql`, a `SqlServerVersions.sql` helper, an `Uninstall.sql`, and three directories: `Deprecated/`, `Documentation/`, and `OptionalScripts/`.

The names describe a workflow. `sp_Blitz` is the broad health check that the README says to run daily or weekly to get "a prioritized list of issues on your server right now." `sp_BlitzFirst` answers why the server is slow at this moment. `sp_BlitzCache` is historical, surfacing which queries have been consuming the most resources over time. `sp_BlitzIndex` deals with missing and misused indexes. `sp_BlitzLock` parses deadlocks. `sp_BlitzWho` shows what is running right now. `sp_kill` is described in the README navigation as an "Emergency Session Killer," which tells you its intended moment.

There is also an ordering dependency that is easy to miss. The README notes that sp_Blitz requires `sp_ineachdb` installed in the same database, and that the installer handles this for you by placing `sp_ineachdb` first. If you are installing procedures by hand, that ordering is on you.

The `Deprecated/` folder is a genuinely thoughtful touch for a project like this. It holds older versions of the scripts for instances running SQL Server releases that Microsoft itself no longer supports, such as SQL Server 2008.

Where it runs, and the one place it does not

Platform support is stated unusually directly. SQL Server on Windows works across all versions Microsoft still supports, with a pointer to sqlserverupdates.com for end-of-support dates. SQL Server on Linux is fully supported with exactly one named exception: `sp_DatabaseRestore` requires `xp_cmdshell`, which Microsoft does not provide on Linux. Amazon RDS for SQL Server is fully supported.

Azure SQL Database is the interesting case, because the project supports it more than you would expect and less than you would want. A dedicated `Install-Azure.sql` installs only the compatible subset. The release history for July 2026 added Azure SQL DB compatibility to sp_Blitz, framed as an explicit compromise: the goal was not to replicate the full check set, since backups are irrelevant there, but to skip what cannot be checked and run what matters. The README still warns that Azure is not supported, that Microsoft has "a tendency to change DMVs in Azure without warning," and that fixes are left to the user.

Read together, the guidance is consistent and worth taking at face value: this kit targets self-managed SQL Server. The wider the platform drift, the more the author is explicitly declining to chase it. For anyone running a heavily managed cloud instance, a purpose-built native tool is likely the better investment.

Installing it and running a first check

Installation is deliberately dull, which is a compliment. The README's instruction is to download the latest release ZIP and then run the SQL files in the `master` database, adding that you can use another database if you prefer. For the all-in-one path, open `Install-All-Scripts.sql` in SSMS or Azure Data Studio, pick the target database, and run it. It will install the procedures if they are missing or update them to the current version if they already exist.

The two files that matter for a first run:

Install-All-Scripts.sql
Install-Azure.sql

Use the first for SQL Server on Windows, Linux, or RDS, and the second when you are on Azure SQL DB.

The README does caution against scattering copies across several databases. The procedures work in any database, but you may fail to keep every copy current, and an out-of-date duplicate is its own kind of incident. `master` is the recommendation for that reason.

PowerShell users have a separate path. The July 2026 release added `Install-DbaFirstResponderKit` through dbatools, so the install can be scripted alongside the rest of a provisioning pipeline rather than done by hand in a management studio window.

Support is a Slack channel staffed by volunteers

This is the part of the project that most distinguishes it from a commercial monitoring product. The README routes questions to a `#FirstResponderKit` channel on SQL Community Slack, and then adds a sentence worth quoting for its tone: "Be patient - it's staffed with volunteers who have day jobs, heh."

The support path is documented as a sequence rather than a single destination. Read the "More Details" URL attached to any warning the scripts produce, because the project puts real effort into that documentation. Ask in the Slack channel when you need to know how a tool behaves. Post at DBA.StackExchange.com when the question is really about how SQL Server works, and the README asks you to include exact errors, screenshots, your SQL Server version including the build number, and the version of the tool.

Bug reports and change requests go through `CONTRIBUTING.md`, and everyone participating is expected to follow the Contributor Covenant code of conduct.

The licensing is MIT, per both the README section title and the `LICENSE.md` file in the tree. Note that the repository metadata reports no license identifier, so the `LICENSE.md` file and the README heading are the authoritative signal here. MIT is permissive enough that the scripts can be embedded in your own internal tooling without much friction, though it is not legal advice and your own reviewers should confirm the fit.

2026 shows the project moving faster, with AI attached

The release history is the clearest evidence of direction. Three releases in 2026 tell a consistent story: faster iteration, more machine assistance, and a growing AI surface area.

The March 2026 release introduced AI advice in `sp_BlitzIndex`. The release notes show a single call to `sp_BlitzIndex` with a table name and an `@AI` parameter set to 2.

The result set returns advice drawn from ChatGPT or Gemini, rendered in Markdown so it can be pasted into client-facing recommendations. The release note's tone is self-deprecating about the cause: "It's Friday the 13th: what could possibly go wrong with a heavily AI-driven release?" The same note credits AI for the pace, pointing out that the kit had shipped a large update only the month before.

April 2026 is the release the author explicitly tells you to skip. It is described as "a release you should skip for reliability reasons," put out early only so adopters could experiment. It carried the `@AI` parameter for single-table index consolidation advice, a breaking change to the AI configuration tables used by `sp_BlitzCache` and now `sp_BlitzIndex`, and a migration script for anyone who had already started using the old structure. It also replaced a long-stale PDF setup document with a new markdown checklist in `Documentation/`, which is a quietly useful cleanup for anyone whose runbooks still point at the old file.

July 2026 then changed the release model itself. From that point the author publishes annual named releases, starting with the First Responder Kit 2026, while continuing to ship more frequently on GitHub without writing a blog post each time. Classes were synced to the same annual features.

That April warning is worth weighing carefully. It describes heavy AI-authored code entering a toolkit whose entire value proposition is being the thing you trust at three in the morning. Taking it as a deliberate signal rather than a passing remark is the right call.

Who is it for

The First Responder Kit rewards a specific kind of operator. It suits a DBA or developer who is comfortable running a stored procedure, can interpret DMV output, and wants to answer a question right now without provisioning anything. For that person it is genuinely excellent: fast, local, transparent, and free.

It suits an organization less well if you need continuous monitoring with alerting and history, a supported contract with someone to call, or coverage across a fleet heterogeneous enough that no single install target exists. The scripts can be scheduled, and the community will help you schedule them, but that is you building the monitoring product.

The project's ongoing health is good. The most recent push to the repository was September 19, 2026, only weeks before this article was written, and the 2026 release cadence shows real work rather than maintenance. At roughly 3,900 stars, 1,100 forks, and two open issues, the risk here is not abandonment. It is the ordinary risk of any dependency you run with elevated permissions against a production instance: know which version you installed, read the release notes before upgrading, and keep the scripts in a database you can actually manage.

Editorial conclusion

The First Responder Kit is what it has always been: a fast, local, free set of diagnostics that runs where the problem is. Its 2026 releases show an active project accelerating its cadence and leaning into AI-assisted analysis, and the explicit warning attached to the April 2026 release is honest about the cost of doing that quickly. Install it, read the release notes before you upgrade, and it will earn its place in the cabinet.

Frequently asked questions

Official sources

1. BrentOzarULTD/SQL-Server-First-Responder-Kit on GitHub
2. Issues
3. Project website
4. README
5. Releases