When Did SQL Server Last Restart? Four Ways to Check

Nearly empty counters on a slow server call for a timeline before another tuning change. Finding the last restart tells you whether today's numbers describe a full workday or just the opening minutes.

Start With the Engine's Own Last Restart Timestamp

SQL Server exposes its startup time directly through sys.dm_os_sys_info. This is my first check when an incident report mentions missing cache history. I record the instance name alongside the timestamp before comparing anything else.

The following query targets SQL Server on Windows, including SQL Server 2025. Run it against the actual instance being investigated. A listener connection can reach a different replica after failover, so confirm the connected server identity.

SELECT
    CONVERT(nvarchar(128), SERVERPROPERTY('ServerName')) AS ServerName,
    sqlserver_start_time AS EngineStartLocal,
    SYSDATETIME() AS CapturedLocal,
    (ms_ticks - sqlserver_start_time_ms_ticks) / 1000 AS UptimeSeconds
FROM sys.dm_os_sys_info;

The startup datetime uses the local system clock. The tick calculation provides an elapsed interval without subtracting two wall-clock timestamps. Preserve the capture time because a saved result becomes historical evidence immediately after collection.

A Windows restart and a SQL Server service restart are separate events. Restarting the database engine does not require restarting Windows. Identify which event your question concerns before comparing this result with operating system records.

Confirm the Last Restart With tempdb

SQL Server recreates tempdb when the engine starts. Its database creation timestamp therefore supplies another practical startup clue. Query the catalog instead of relying on a file timestamp from Windows Explorer.

SELECT name, create_date AS TempdbCreatedLocal
FROM sys.databases
WHERE database_id = 2;

Expect these timestamps to describe the same startup sequence, rather than matching every fractional second. Initialization work separates individual startup events. A small difference between engine initialization and tempdb creation does not establish another restart.

This method concerns the tempdb belonging to the connected instance. It does not tell you when an application database was restored. It also does not identify the application deployment that happened near the same time.

I use independent checks because timestamps become persuasive when their meanings agree. Two identical-looking dates from unrelated events provide weaker evidence than two explained dates. Write the event beside each date in your incident notes.

Read the Startup Messages in the Error Log

The error log provides narrative context that a single timestamp cannot supply. Startup messages can place recovery, configuration changes, and database initialization around the last restart. Search the current engine log first, then inspect retained archives when needed.

EXEC master.sys.sp_readerrorlog
    @p1 = 0,
    @p2 = 1,
    @p3 = N'SQL Server is starting';

EXEC master.sys.sp_enumerrorlogs;

Log number zero means the current log, while log type one selects the database engine. Search text must match the message language and wording on your instance. If the narrow search returns nothing, inspect the beginning of the relevant log directly.

A log can be cycled without restarting SQL Server. Consequently, the creation of the current log does not prove an engine startup. The latest startup message can reside in an archived log after routine log cycling.

Retained archives are finite, so missing startup text is inconclusive. Record the archive number and message timestamp when you find the relevant entry. Do not cycle logs during evidence collection just to make the list tidier.

Treat Session One as Weak Corroboration

An internal session with session_id equal to one can provide another timestamp to inspect. Its login_time records when that session was established. This is a corroborating technique, rather than the documented engine startup field.

SELECT session_id, login_time, is_user_process, status
FROM sys.dm_exec_sessions
WHERE session_id = 1;

Check whether the row is visible and represents an internal session. Compare its timestamp with engine metadata and startup messages. If the row is absent or inconsistent, preserve that observation and trust the documented startup field.

On my SQL Server 2025 test instance, session 1 had logged in hours after the engine started. The other three checks agreed with each other within seconds. So treat this one as a hint, never as the deciding vote.

Do not replace this query with the oldest visible application login. Connection pools and disconnected clients make that timestamp a different event. A long-lived connection is not an official clock for database engine uptime.

The four checks answer related questions with different evidence. Engine metadata identifies startup, tempdb records recreation, logs explain events, and session metadata records establishment. Agreement supports the timeline without pretending every source has identical authority.

Explain Why Performance Numbers Changed

Many cumulative DMV values cover activity since engine startup. A restart therefore removes important historical context from the current in-memory counters. Comparing those totals with yesterday's larger totals without checking uptime produces a misleading conclusion.

Cached query and procedure statistics have additional boundaries. Cache eviction, recompilation, and explicit cache clearing can remove individual entries without an engine restart. A surviving entry describes its own cache lifetime, rather than every execution since installation.

Wait statistics can also be reset explicitly. Database-level events and replica changes introduce further scope differences. Treat each counter's reset conditions as part of its definition before calculating a rate or ranking a workload.

Store snapshots with instance identity, capture time, and startup time. Calculate interval differences only when both snapshots belong to the same relevant lifetime. Negative differences or missing rows require explanation, rather than conversion into reassuring zeroes.

Investigate a Cold Cache Without Restarting Again

After startup, data pages and execution plans need to enter their caches again. Compilation and physical reads can contribute to slower early requests. That explanation is a hypothesis to verify, rather than a reason to stop investigating.

Compare repeated executions using representative parameters and the same workload conditions. Inspect reads, waits, CPU, and plan behavior together. Do not clear production caches to recreate the incident while other requests are running.

Is the first execution slow while subsequent executions settle, or does every execution remain slow? That distinction guides the next diagnostic step. Cache warm-up cannot explain an ongoing blocking chain by itself.

A server is allowed to wake up slowly; the incident report should still wake up accurately. Check storage latency, recovery activity, and connection retries around the startup window. Preserve evidence before another maintenance action changes the available history.

Save a Last Restart Timeline Another Person Can Verify

SQL Server 2022 and later require VIEW SERVER PERFORMANCE STATE for the engine metadata query. Earlier versions use VIEW SERVER STATE. Session visibility and error-log access also depend on the granted permissions for the installed version.

For current releases, error-log reading accepts VIEW ANY ERROR LOG or VIEW SERVER PERFORMANCE STATE. Request the narrow access needed for investigation. An empty result under limited visibility is not proof that an event never occurred.

Finish with the recorded last restart and the evidence supporting it. Separate service startup, log cycling, database recovery, and cache-entry creation in the notes. That timeline gives subsequent tuning work a reliable starting point.

Related reading on this blog: Script: Find Last System / Operating System Reboot or Restart Time and PowerShell Script: When Was SQL Server Last Restarted?.

A restart timestamp is not a performance diagnosis, it is the boundary that makes performance evidence interpretable.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.