SQL Server becomes slow during peak hours but appears normal later. How would you investigate it?

The investigation should capture evidence during the peak period rather than relying only on the system after the problem disappears.

Establish the time window and inspect Query Store, monitoring history, Extended Events, wait-stat deltas, CPU, storage latency, memory pressure, tempdb usage, blocking, deadlocks, active sessions, memory grants, transaction-log latency, and connection/workload volume.

Identify which queries consumed the most resources during the affected period and compare their plans and runtime statistics with normal periods. Also check application changes, scheduled SQL Agent jobs, backups, ETL, index maintenance, reporting, and external workload spikes.

The key senior-level interview point is to correlate SQL Server symptoms with the exact time window and workload. A server that looks healthy after peak time does not prove that CPU, I/O, blocking, memory, or concurrency were healthy during the incident.