SQL Server weekly checklist: 10 checks
Use the same ten checks each week, but spend your time on exceptions. Mark each production instance or service group OK, Follow up, or Urgent. The review is finished when every exception has a next step, an owner, and a date.
| Check | What you are trying to confirm | Follow up when |
|---|---|---|
| 1. SQL Server Agent jobs | Every expected run finished in its normal window and notifications arrived | A run is missing, failed, retried, unusually slow, or unreported |
| 2. Backups and restore tests | Backup coverage matches the recovery plan and a recent restore test succeeded | The recovery target was missed or the latest restore test is stale, slow, or failed |
| 3. Database integrity | Every database is covered by the intended CHECKDB schedule | A database was skipped, the check stopped early, or CHECKDB reported errors |
| 4. Capacity and file growth | Storage growth is understood and there is enough time to act | A volume may fill, autogrowth keeps repeating, or log and tempdb growth has no clear cause |
| 5. Query performance | Comparable workloads still use roughly the same time and resources | A query, plan, or workload became materially slower or more expensive |
| 6. Blocking, deadlocks, and waits | Contention is understood and recurring patterns have been captured | The same blocker, object, deadlock, or wait pattern keeps returning |
| 7. Logs and alert delivery | Important log entries were reviewed and alert routes reached a real recipient | An error needs action or a notification stopped before the final recipient |
| 8. HA and data movement | Replicas are moving data within target and failover dependencies are in place | A queue is outside target, movement stopped, or a secondary is missing jobs, logins, or backups |
| 9. Recent changes | Deployments and temporary changes were validated and closed | A new symptom matches a change or temporary work has no owner or removal date |
| 10. Next-week actions | Every exception has a clear next step, owner, and date | A production risk or recurring problem remains unassigned |
Set up the weekly review before you start
Pick a complete seven-day window and use the same cutoff each week. Keep the previous equivalent week available for comparison. Month end, overnight imports, reporting cycles, and other scheduled workloads can change the numbers enough to make a quiet week a poor baseline.
Start with an inventory of the instances, databases, expected jobs, recovery targets, HA roles, monitoring locations, and owners. Gather the result for every expected system. A missing row is a finding until you know why it is missing; it can mean a new database was never added to a job or that history was removed before the review.
Use a login with the read-only monitoring access needed for the relevant system views, msdb history, Query Store, and HA views. Some checks need VIEW SERVER STATE or SQL Server Agent roles. If access hides part of the result, record that limit instead of marking the check OK.
Collect first and review by exception. Keep production changes, restore tests, failovers, and heavy integrity work in their own approved windows. The checklist is for self-managed SQL Server on Windows or Linux. Azure SQL Managed Instance shares several checks, but its backup and HA responsibilities differ. Use the daily operations checklist for failures that need attention now.
- Use one fixed seven-day window.
- Collect every expected instance and database.
- Compare with the previous equivalent workload period.
- Record exceptions and access gaps without changing production during the review.
Make sure scheduled jobs really ran
SQL Server Agent can finish a job after a retry, skip a scheduled run, or complete later than usual without creating an obvious current alert. The weekly review compares the work that should have run with the history Agent actually kept.
Where to look
SQL Server Agent in SSMS under Jobs and View History, plus msdb.dbo.sysjobs, sysjobhistory, and the Agent error log.
How to check it
- 1.Export the expected enabled jobs and schedules. Check that Agent history still reaches the start of the seven-day window.
- 2.Run the query below and match each expected run to an outcome. Open the full step message for failures, retries, cancellations, and unexpected step flow.
- 3.Compare duration with the same job during a similar workload period. Confirm that a real operator, mailbox, or ticket route received the failure notification.
What the result means
A missing run is different from a failed run: it may point to a disabled schedule, stopped Agent service, role-aware job logic, or lost history. A successful outcome with retried steps still needs review when the retry affected timing or downstream work.
Seven days of SQL Server Agent history
Returns completed job outcomes, then failed, retried, and canceled steps from msdb. Run it on each SQL Server instance.
SQL Server Agent history is subject to instance-wide and per-job row limits. The query cannot tell you that an expected schedule never existed; compare it with your approved job list. Members of SQL Server Agent roles may see fewer jobs than sysadmin.
Check whether the backups can be restored
Backup jobs can stay green while a new database is missing, a log-backup schedule has gaps, or the latest restore test is too old. Review coverage for every database and confirm that a controlled restore has exercised the recovery path.
Where to look
Native backup and restore history in msdb, the backup product console when a third-party tool owns the process, backup-job output, and the controlled restore-test record.
How to check it
- 1.Run the history query and compare full, differential, and log times with the documented RPO for every database, including databases created or restored this week.
- 2.Open the backup job or tool output for gaps, destination changes, checksum warnings, unusual size, and unusual duration. A missing scheduled log backup is an RPO miss even when a later log backup succeeds.
- 3.Find the latest controlled restore test. Record the chosen recovery point, restore duration, encryption keys or certificates used, CHECKDB result where applicable, and an application or data-access smoke test.
What the result means
A recent timestamp in msdb is useful history, not a restore guarantee. RESTORE VERIFYONLY checks that the backup set is complete and readable, but it does not restore the database or check the internal data structure. Third-party or snapshot backups may also require their own authoritative history.
Latest backup and restore history
Shows the latest native full, differential, and log backup recorded for each database, plus the latest restore recorded under the same destination database name.
Run in the instance that owns the backup history. Aggressive msdb cleanup can make valid backups disappear from this result. A restore performed on a separate test instance will be recorded on that test instance, so keep a central restore-test record.
The SQL Server backup guide covers log-chain review, backup options, and restore testing in more depth.
Confirm every database had an integrity check
A successful integrity job only shows that its configured work finished. The weekly review checks which databases were included, what CHECKDB options ran, where the output was stored, and whether any database was skipped or reported an error.
Where to look
The integrity job's command table or output files, SQL Server Agent step history, SQL Server error log, and the current list in sys.databases. Custom maintenance frameworks should use their own command log as the main source.
How to check it
- 1.List every online database and include
master,model, andmsdb. Treattempdbseparately because CHECKDB cannot create its normal internal snapshot there. - 2.Match every database to a completed integrity run. Record the command, options, start time, duration, outcome, and stored output. Check whether the job used
PHYSICAL_ONLY. - 3.Open every failure or warning. Save the complete output and check related SQL Server, operating-system, and storage errors before planning recovery work.
What the result means
The query below finds likely Agent jobs; it cannot prove per-database coverage when a stored procedure builds the database list dynamically. PHYSICAL_ONLY skips logical checks and needs periodic full CHECKDB coverage. Choose the cadence from database size, recovery needs, workload, and available maintenance capacity.
Locate integrity jobs and recent execution
Finds Agent steps that appear to run DBCC CHECKDB or a common integrity procedure, then shows their most recent recorded run and failures.
No rows can mean the check runs outside SQL Server Agent or is hidden behind a custom procedure. The result identifies likely jobs; compare the command or command log with the full database inventory. Do not run repair options from a weekly review.
Use the maintenance plan guide when integrity jobs, output retention, or maintenance windows need redesign.
Look for storage pressure before space runs out
Capacity problems usually build over several days or weeks. Compare stored measurements for volumes, data files, transaction logs, tempdb, and backup storage so there is enough time to investigate growth and arrange more capacity.
Where to look
Host or infrastructure monitoring for historical volume free space, SQL Server file metadata, backup storage monitoring, and sys.databases.log_reuse_wait_desc for the current log reuse reason.
How to check it
- 1.Run the query and export the result with the week-ending date. Compare volume free space and file sizes with the previous equivalent week.
- 2.Review monitoring or file-growth events for repeated data, log, and tempdb autogrowth. Check whether the configured increment is a fixed size or a percentage.
- 3.For log growth, read
log_reuse_wait_descand inspect the matching backup, active transaction, availability, replication, or workload history. Estimate when the volume could reach the agreed capacity limit.
What the result means
One current free-space value cannot provide a weekly growth rate. DMV and file metadata need stored snapshots or monitoring history. Autogrow is contingency capacity, not the planned way to size a database. Different log reuse waits need different investigation.
File, volume, and log reuse state
Lists database files, growth settings, hosting-volume capacity, and the current transaction-log reuse wait.
sys.dm_os_volume_stats requires permission to view the relevant server state. The query is a current reading; retain the output or use monitoring data to calculate growth. The same volume can appear once for every file stored on it.
Use the SQL Server sizing guide when the finding needs a proper capacity forecast or storage design change.
Compare query performance with a normal week
Small query regressions can remain hidden until workload increases. A weekly comparison finds queries and plans that used more time or resources during an equivalent business period, while accounting for changes in execution count and rows processed.
Where to look
SSMS under the user database at Query Store → Regressed Queries or Top Resource Consuming Queries, plus Query Store runtime and plan views and the monitoring repository.
How to check it
- 1.Confirm Query Store is read-write and retains the full current and comparison periods. Choose two windows with a similar business workload.
- 2.Compare average duration, CPU, logical reads, writes, execution count, and row count. Open the plan history when a query changed materially.
- 3.Record the database, query ID, plan ID, both time windows, the measure that changed, nearby deployments or maintenance, and the next diagnostic check.
What the result means
A changed average with similar execution count is a stronger regression candidate than a higher weekly total. A different plan can explain the timing, but it does not automatically make plan forcing the right fix. Query Store gaps are themselves monitoring findings.
Compare two Query Store weeks
Run inside one important user database. It returns plans seen during the last 14 days with execution, duration, and logical-read averages for each seven-day period.
Query Store views are database-scoped and need Query Store to retain both periods. The query uses UTC Query Store interval times; align the periods with the business workload and local reporting convention. Review plan XML, parameters, rows, and nearby changes before recommending a production change.
The SQL Server monitoring guide covers the collection needed when Query Store or performance history is missing.
Find recurring blocking, deadlocks, and waits
Blocking and deadlocks often finish before anyone opens SSMS. Review saved captures across the week to find the same head blocker, application operation, database object, deadlock shape, or wait pattern appearing repeatedly.
Where to look
The monitoring repository, blocked-process reports, long-transaction captures, the built-in system_health session for recent deadlock XML, and a dedicated Extended Events session when longer retention is needed.
How to check it
- 1.Filter captures to the seven-day window and group blocking by head blocker, application, database, object, and time of day. Keep the full chain and transaction age.
- 2.Open every deadlock graph. Compare processes, resources, statements, isolation levels, and application operations instead of reviewing only the victim.
- 3.Compare wait deltas for meaningful workload intervals, excluding expected idle waits. Link the repeated pattern to the next query, transaction, indexing, or application investigation.
What the result means
Repeated shape matters more than one short wait. The same application operation or object across several captures gives the investigation a useful starting point. A weekly historical result does not justify killing a current session or changing isolation settings.
Use the wait, blocking, and deadlock guides for the actual diagnosis and safe live checks.
Read the logs and confirm alerts arrived
Repeated warnings, short service restarts, and notification failures are easy to miss when each day is reviewed separately. Read the full log window and confirm that important events reached the mailbox, ticket queue, or monitoring route people use.
Where to look
SSMS under Management → SQL Server Logs and SQL Server Agent → Error Logs, archived log files, Windows Event Viewer or the Linux journal, Database Mail history, and the external monitoring event timeline.
How to check it
- 1.Search the current and archived SQL Server logs for unexpected starts, recovery messages, stack dumps, I/O errors, database state changes, failed logins where relevant, and recurring warnings. Match the time with host logs.
- 2.Review Agent and Database Mail logs for failed notifications. Pick an important event from the week and confirm the final recipient received it.
- 3.When no suitable event fired, run an approved Database Mail or monitoring delivery test. Record the originating rule, recipient, delivery state, and test time.
What the result means
A successful Database Mail test checks the mail path. It does not prove that Agent notifications, severity alerts, or external rules are configured correctly. An important event with no delivered message is a separate alerting failure.
Check HA data movement and failover dependencies
A healthy HA dashboard now does not describe the whole week. Review data-movement history, queue growth, suspensions, role changes, and the jobs, logins, paths, and backup logic needed on the server that would take over.
Where to look
Availability Group DMVs and dashboard, log shipping or replication monitors, Agent history on every host, backup history, login and job inventories, and the latest controlled failover record.
How to check it
- 1.Run the query on each replica. Check connection, synchronization, suspension, send and redo queues, and preferred backup status against the role and recovery target.
- 2.For log shipping or replication, inspect the backup, copy, restore, reader, distribution, merge, or snapshot job chain and its recorded latency.
- 3.Compare jobs, owners, credentials, paths, and relevant logins across failover partners. Confirm backup jobs use preferred-replica logic and that backups still exist independently of the secondary.
What the result means
There is no useful universal queue threshold. Judge queue size and catch-up time against workload and recovery targets. An asynchronous secondary can normally report SYNCHRONIZING. Agent jobs and logins are instance objects and do not move with an availability database.
Availability Group state and backup preference
Shows replica and database health, suspension, queue sizes, and whether the local replica is preferred for backup. Run on every replica for a complete view.
Availability Group DMV visibility differs between the primary and secondary replicas. VIEW SERVER STATE or the version-appropriate server performance permission is required for full DMV output. Queue values are current readings; use monitoring history to review the full week.
Use the SQL Server failover guide to prepare a controlled failover test with application validation and rollback.
Match new problems to recent changes
New failures and performance changes often appear close to a deployment, patch, permission update, infrastructure change, or temporary workaround. Put those events on one timeline to give the next investigation a sensible starting point.
Where to look
Change tickets, deployment pipelines, source-control releases, SQL Audit or approved audit output, configuration repositories, patch records, and the temporary-change register.
How to check it
- 1.List every change that touched the SQL Server host, instance, database, application connection, storage, network, or monitoring route during the review window.
- 2.Match the time and affected systems with new job failures, backup gaps, performance regressions, alerts, or HA events. Record the validation that ran after each change.
- 3.Find temporary work: disabled jobs, forced plans, trace flags, exclusions, emergency settings, and temporary permissions. Confirm each has an owner, review date, and removal or acceptance decision.
What the result means
SQL Server cannot reliably reconstruct every past configuration, deployment, or permission change after the event. Missing history is a collection gap. Record what must be audited next time instead of guessing from the current configuration.
Use the SQL Server patching guide when the recent work needs a controlled validation or rollback plan.
Leave every finding with an owner
Findings without a clear next step tend to return in the following review. Turn each exception into a small work item that names the affected system, current impact, owner, due date, and the first action to take.
Where to look
The service desk, engineering backlog, change system, or another shared record that the owner and the next weekly reviewer can open.
How to check it
- 1.Group duplicate symptoms into one finding, but keep every affected instance or database listed.
- 2.Put current recovery, integrity, availability, and production risks first. Choose the next diagnostic or scheduling action, not a guessed fix.
- 3.Name one accountable owner role and one due date. If work depends on a test system, vendor response, approval, or maintenance window, make that dependency the next dated action.
What the result means
A useful action is specific enough to move before the next review. “Investigate performance” is too broad. “Compare Query Store plans 918 and 921 for the weekday order search by Friday” gives the owner a starting point and a finish condition.
Copyable weekly review record
Week ending: SQL Server instances reviewed: Status: OK / Follow up / Urgent Failed or slow jobs: Backup or restore concerns: CHECKDB gaps or errors: Capacity and file-growth concerns: Performance regressions: Blocking or deadlocks: Log or alert problems: HA/replication concerns: Recent changes needing follow-up: Next action | Owner | Due date
Keep production changes out of the review
Investigation and change control are separate jobs. The weekly review can recommend work, but each production change still needs testing, approval, a maintenance window where required, monitoring, and a rollback plan. This is especially important when the proposed fix changes query plans, files, server configuration, or failover behaviour.
Weekly does not mean rebuild every index, shrink every file, or install every patch. Base index maintenance on measured workload and use. Plan SQL Server patching with compatibility checks, working backups, a tested rollout, and rollback. Give every approved change success criteria and post-change checks.
SQL Server weekly review questions
Does every SQL Server need the same checklist?
Use the same ten subjects, then define the expected result for each system. A small reporting instance may have different backup schedules, recovery targets, HA checks, and escalation routes from a revenue-critical transactional system.
Should every weekly check be manual?
Automate the collection and immediate failure alerts. Keep the human review for comparing periods, interpreting exceptions, noticing missing notifications, and deciding what happens next. If the weekly meeting is spent collecting basic job and backup history, that is the first part to automate.
How long should the weekly SQL Server review take?
It depends on the estate and the number of exceptions. A healthy week should be quick when central reports collect the results. The review takes longer when a restore failed, capacity changed sharply, or a recurring performance problem needs to be handed into a proper investigation.
Need help automating these SQL Server checks?
If this review still depends on opening every server and copying results by hand, I can set up the collection, reports, and alerts. A SQL Server health audit shows which checks already run, where the gaps are, and what is worth automating first. You can also request a quote for the review.
Next step
Use the SQL Server stability review guide when the same performance, capacity, maintenance, or ownership problems keep returning.
Use the SQL Server environment assessment guide when you need to map the wider estate, dependencies, ownership, and readiness for planned work.
Microsoft sources
- SQL Server Agent error log
- Set up the SQL Server Agent job history log
- SQL Server Agent sysjobhistory table
- Set job-step success, failure, and retry flow
- SQL Server backupset history table
- SQL Server restorehistory table
- RESTORE VERIFYONLY
- Restore a SQL Server database backup
- DBCC CHECKDB
- Troubleshoot CHECKDB consistency errors
- SQL Server transaction log
- sys.dm_os_volume_stats
- sys.databases catalog view
- Autogrow and autoshrink considerations
- Monitor performance with Query Store
- Query Store runtime statistics
- SQL Server performance monitoring
- Use the system_health Extended Events session
- View the SQL Server error log
- Send a Database Mail test email
- Always On availability groups
- Availability Group database replica states
- Preferred backup replica function
- Manage jobs and logins for availability groups
- Optimize SQL Server index maintenance

