SLEEP_DBSTARTUP and Startup Sleep Wait Types in SQL Server

Three sleep waits measure phases of instance startup, and this page covers them together:

• SLEEP_DBSTARTUP: the thread driving parallel database startup sleeping between checks that all databases have recovered. Its useful property: once startup completes, this wait’s cumulative time equals how long parallel database recovery took, a free metric.
• SLEEP_DCOMSTARTUP: waiting during DCOM initialisation early in instance startup.
• SLEEP_MASTERDBREADY: waiting for the master database to finish recovery, which gates everything else.

They fire once per startup and then go quiet until the next one.

Are They a Problem?

Not as waits; they are startup phase markers on the benign filter list. Their value is forensic: SLEEP_DBSTARTUP‘s total after a restart tells you your database recovery time at a glance, worth checking after patching windows and failovers, and worth trending if startup keeps getting slower.

Slow startups have real causes worth chasing through these markers: many databases recovering in parallel but bounded by worker threads, huge transaction logs replaying (VLF bloat historically made this brutal), and in-memory OLTP databases loading data into memory.

What To Do

1. Filter them from routine analysis, but note SLEEP_DBSTARTUP‘s total after restarts as your recovery-time metric.
2. For slow startups: check VLF counts (our Get-VlfCount script; thousands of VLFs slow recovery), crash recovery progress messages in the error log, and which databases take longest.
3. Keep logs healthy (sensible size and growth) and consider ADR on 2019+ for databases with long-undo workloads; both shrink recovery time.

How To See It

Rank waits with Get-WaitStatistics right after a restart, before workload noise accumulates, and the startup story reads cleanly.

---

Part of the SQL Server Wait Types Library.
Related deep dive: WRITELOG Wait Type.