sp_Blitz: divide by zero in CheckID 152 when the server has been up less than a minute

[BrentOzar]

Describe the bug

Running sp_Blitz within the first minute of SQL Server starting aborts with:

Msg 8134, Level 16, State 1, Procedure dbo.sp_Blitz, Line 9764
Divide by zero error encountered.

sp_Blitz stops at that point and returns nothing further.

Root cause

sp_Blitz.sql#L1261 computes the value in whole minutes:

SELECT @MsSinceWaitsCleared = DATEDIFF(MINUTE, create_date, CURRENT_TIMESTAMP) * 60000.0

Under one minute of uptime that DATEDIFF is 0, so @MsSinceWaitsCleared is 0.

There is a zero-guard, at L1272:

IF @MsSinceWaitsCleared = 0 SET @MsSinceWaitsCleared = 1;

but it sits inside the block opened at L1266:

IF @MsSinceWaitsCleared * .9 > (SELECT MAX(wait_time_ms) FROM sys.dm_os_wait_stats WHERE ...)

When @MsSinceWaitsCleared is 0, that predicate is 0 > MAX(wait_time_ms), which is never true. The branch is skipped, so the guard never runs, and the zero survives to CheckID 152:

CAST(CAST((SUM(60.0 * os.wait_time_ms) OVER (PARTITION BY os.wait_type) ) / @MsSinceWaitsCleared AS NUMERIC(18,1)) ...

The guard only fires in the case where it isn't needed.

Steps to reproduce

1. Start SQL Server (or restart the service).
2. Within 60 seconds, run EXEC dbo.sp_Blitz;.

Observed on

SQL Server 2017 Developer (14.00.3540) on Linux, in the CI container added by #4047. Caught on that PR's first run: the base pass started 24 seconds after container startup and hit the divide-by-zero; the second pass, two minutes in, did not. The SQL Server 2025 job never reproduced it because its container took longer to come up and both passes landed past the one-minute mark.

Expected behavior

sp_Blitz completes and returns findings regardless of how recently the instance started.

Suggested fix

Move the zero-guard out of the conditional so it always applies, or clamp at the assignment — e.g. NULLIF(..., 0) with a fallback, or simply follow L1261 with an unconditional IF @MsSinceWaitsCleared = 0 SET @MsSinceWaitsCleared = 1;. Worth checking @CpuMsSinceWaitsCleared just below it for the same shape, since CheckID 152's CTE filter divides against that one.

Impact

Anyone running sp_Blitz right after a restart — which is a fairly natural thing to do when investigating why a server just restarted.

Do you want to build this fix yourself?

Happy to, as a separate PR. Not folding it into #4047, which is CI plumbing; that PR works around the timing instead so its base-vs-head comparison stays apples-to-apples, and links here.