SQL Server Health Check Downloadable Checklist (DBA Runbook for 2026)

Why this checklist exists

Most SQL Server incidents are not “random.” They are predictable patterns that were visible earlier: missed backups, failing SQL Agent jobs, creeping disk latency, growing TempDB pressure, plan regressions, or an ignored corruption warning that later becomes a business outage.

This downloadable checklist is designed to be a repeatable DBA operating system: measure first, document findings, then take safe actions. It works whether you have full monitoring or not.

If you want a deeper troubleshooting playbook, pair this with: Troubleshooting Common SQL Server Performance Issues (DBA Perspective) .

How to use the checklist (the correct workflow)

Step 1: Classify the situation (normal vs warning vs incident)

Before “fixing,” determine which mode you’re in:

• Normal: routine checks, capture evidence, record results
• Warning: a failure exists but business impact is limited (example: one job failing)
• Incident: customer impact (timeouts, errors, data risk) — prioritize stabilizing service

Step 2: Verify recoverability first

A DBA’s highest priority is recoverability. Always start with backups and restore readiness. Microsoft’s backup and restore guidance is here: SQL Server backup overview and restore & recovery overview .

Step 3: Capture evidence (so you can prove you checked)

Each checklist item includes an “evidence” suggestion—query output, screenshot, job history export, or a short note. This makes your work defensible and repeatable.

Daily vs Weekly vs Monthly checks (what matters most)

Daily (10–15 minutes): catch silent failures

• Backups completed: full/diff/log are current for the environment
• SQL Agent job failures: investigate any failure in the last 24 hours
• Error log scan: repeating issues, login storms, I/O warnings, corruption signals
• Blocking visibility: confirm no long-running blocking chains during peak time
• Disk free space: confirm safe headroom (data/log/tempdb + backup volume)

Weekly (30–60 minutes): prevent performance regressions

• Restore readiness: verify you can restore (not just “backups exist”)
• Query Store review: detect plan regressions and top resource queries
• Waits trend: compare week-over-week (not just single snapshots)
• I/O hotspots: identify rising latency at the file level

Official Query Store documentation: Monitoring performance using Query Store and managing Query Store .

Monthly (1–3 hours): reduce long-term operational risk

• Consistency checks: schedule DBCC CHECKDB strategy appropriate to your environment
• Patch posture: OS + SQL Server updates planning (avoid emergency patching)
• Security review: permissions drift, unused logins, audit posture
• Capacity planning: growth, tempdb sizing, log growth patterns, retention strategy
• HA/DR validation: confirm RPO/RTO assumptions still match the business

For integrity checking, Microsoft’s DBCC CHECKDB reference: DBCC CHECKDB (Transact-SQL) and troubleshooting guidance: troubleshoot CHECKDB errors .

If you’re building “portfolio proof,” connect this checklist to your learning plan: SQL Server DBA Training & Certification (2026 Roadmap) .

Printable checklist (copy, print, and use)

This section is designed to be printable. If you prefer a PDF, use the download above.

Want deeper technical practice projects? This pairs well with: Managing Large Data Volumes in SQL Server and DBA Survival Guide for SQL Server Upgrades .

Evidence capture + one-page health report template

The fastest way to build trust (and prevent confusion) is to produce a lightweight report after each run. Keep it short, consistent, and attached to the ticket or shared folder.

Server: [NAME]
Date/Time: [YYYY-MM-DD HH:MM]
Run Type: Daily / Weekly / Monthly

Summary (3 bullets)
- Backups: [OK / Issues]
- Jobs: [OK / Issues]
- Performance: [Stable / Degrading / Incident]

Findings
- [Finding] → [Impact] → [Next Action] → [Owner] → [Due Date]

Actions Taken
- [What you changed or escalated] (include ticket/approval)

Attachments/Evidence
- [Link to query outputs / screenshots / job history exports]

If your goal is job placement, connect your runbook work to your career track: Careers at SQL DBA School .

Safe starter queries (read-only)

These queries are designed for visibility—they do not change configuration or data. For deeper scripts, use the internal script library: SQL Server DBA Scripts (All-in-One) .

A) Recent backups (per database)

SELECT
    d.name AS database_name,
    MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS last_full_backup,
    MAX(CASE WHEN b.type = 'I' THEN b.backup_finish_date END) AS last_diff_backup,
    MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS last_log_backup
FROM sys.databases d
LEFT JOIN msdb.dbo.backupset b
    ON b.database_name = d.name
GROUP BY d.name
ORDER BY d.name;

B) Failed SQL Agent jobs (recent)

SELECT TOP (50)
    j.name AS job_name,
    h.run_date,
    h.run_time,
    h.run_duration,
    h.message
FROM msdb.dbo.sysjobhistory h
JOIN msdb.dbo.sysjobs j
    ON h.job_id = j.job_id
WHERE h.step_id = 0
  AND h.run_status = 0
ORDER BY h.instance_id DESC;

C) Blocking visibility

SELECT
    r.session_id,
    r.blocking_session_id,
    r.status,
    r.wait_type,
    r.wait_time,
    r.cpu_time,
    r.total_elapsed_time
FROM sys.dm_exec_requests r
WHERE r.blocking_session_id <> 0
ORDER BY r.wait_time DESC;

D) Wait stats (high-level)

Wait statistics reference: sys.dm_os_wait_stats .

SELECT TOP (20)
    wait_type,
    wait_time_ms / 1000.0 AS wait_time_seconds,
    100.0 * wait_time_ms / SUM(wait_time_ms) OVER() AS pct
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE 'SLEEP%'
ORDER BY wait_time_ms DESC;

E) File-level I/O latency hotspots

Official reference: sys.dm_io_virtual_file_stats .

SELECT TOP (20)
    DB_NAME(vfs.database_id) AS database_name,
    mf.physical_name,
    vfs.num_of_reads,
    vfs.num_of_writes,
    (vfs.io_stall_read_ms / NULLIF(vfs.num_of_reads, 0)) AS avg_read_ms,
    (vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes, 0)) AS avg_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs
JOIN sys.master_files mf
    ON vfs.database_id = mf.database_id
   AND vfs.file_id = mf.file_id
ORDER BY (vfs.io_stall_read_ms + vfs.io_stall_write_ms) DESC;

Automation: schedule & log results (simple, DBA-friendly)

A checklist only works long-term if it’s repeatable. The most common approach is: SQL Agent job runs daily → writes summary rows into a logging table → you review exceptions.

1) Create a health check log table

CREATE TABLE dbo.DBA_HealthCheckLog
(
    HealthCheckLogId     bigint IDENTITY(1,1) PRIMARY KEY,
    CheckUtcTime         datetime2(0) NOT NULL DEFAULT SYSUTCDATETIME(),
    ServerName           sysname      NOT NULL DEFAULT @@SERVERNAME,
    CheckType            varchar(20)  NOT NULL,  -- Daily / Weekly / Monthly
    CheckName            varchar(200) NOT NULL,
    Status               varchar(20)  NOT NULL,  -- OK / WARN / FAIL
    Details              varchar(max) NULL
);

2) Example insert (backup freshness status)

INSERT dbo.DBA_HealthCheckLog (CheckType, CheckName, Status, Details)
SELECT
    'Daily' AS CheckType,
    'Backup Freshness (Last Full/Diff/Log)' AS CheckName,
    CASE
        WHEN EXISTS (
            SELECT 1
            FROM sys.databases d
            LEFT JOIN (
                SELECT database_name, MAX(backup_finish_date) AS last_backup
                FROM msdb.dbo.backupset
                WHERE type IN ('D','I','L')
                GROUP BY database_name
            ) b ON b.database_name = d.name
            WHERE d.database_id > 4
              AND (b.last_backup IS NULL OR b.last_backup < DATEADD(HOUR, -24, GETDATE()))
        ) THEN 'WARN'
        ELSE 'OK'
    END AS Status,
    'Review msdb backup history for databases missing recent backups.' AS Details;

3) Optional: add a standardized toolkit

Many DBAs also use trusted community tooling as an additional signal (not a replacement). For example, Brent Ozar’s First Responder Kit: SQL Server First Responder Kit (GitHub) . If you prefer PowerShell-based automation, dbatools provides installers and helpers: Install-DbaFirstResponderKit (dbatools) .

Always test new scripts in non-production first, and follow your organization’s change control policy.

Common mistakes (and how to avoid them)

• Mistake: “Backups exist” without restore validation. Fix: run periodic restore drills and document steps.
• Mistake: Looking at waits once and drawing conclusions. Fix: trend waits week-over-week.
• Mistake: Running CHECKDB unpredictably. Fix: schedule an integrity strategy appropriate for DB size and RPO/RTO.
• Mistake: Only reacting to incidents. Fix: treat this checklist like preventive maintenance.
• Mistake: No documentation. Fix: use the one-page report template every time.

If you’re training for real roles, explore structured courses: SQL Tutorial for Beginners and Microsoft SQL Server Essential Training .

FAQ