How should you respond when you get the dreaded Email/Slack/Text/DriveBy from someone yelling at you that SQL Server is slow?
Stop. Don’t Open SSMS Yet.
You’ve heard it before: “The server is slow.”
What does that actually mean?
If you jump straight into SQL Server looking for blocking, bad queries, or a missing index, you’re working with bad input. And bad input = wasted time.
The real work starts before you ever connect to SQL Server.
Intake & Scoping Comes First
Your first job is to turn “slow” into something measurable and time-bound. That means gathering evidence, building a timeline, and classifying the type of incident.
Translate “Slow” Into Scenarios
“Slow” can mean very different things depending on who you ask:
- Login delays – Applications take 30 seconds to connect.
- Application lag – a report that usually runs in 2 seconds now takes 30.
- Broad latency – all users complain at once.
- Maintenance overruns – ETL jobs not finishing in their normal window.
- Timeouts or errors – not just lag, but outright failures.
Each one leads you in a different direction.
The Fast Intake Questionnaire
Ask these every single time:
- What exactly was slow? (screen/report/job/login)
- When did it start? (date/time, not “earlier today”)
- How widespread? (one user, team, region, everyone)
- Repeatable? (every time, sometimes, once)
- What changed? (deploys, patches, config, new data)
- Is it happening now? (yes/no)
- Evidence (screenshots, error messages, job names with timestamps)
Classify the Incident
Once you have real answers, put it in a bucket:
- Happening now – live triage needed.
- Recurring/pattern – happens on a schedule.
- Sporadic – random spikes.
- One-time – tied to a patch, deploy, or outage.
Build the Timeline
Anchor events with real timestamps.
- “Around lunch” = useless.
- “9:12 AM CST, FinanceApp login timeout” = actionable.
Capture start, stop, duration, who was affected, and what else was happening on the system at that time.
The (first) Bottom Line:
Action without information is useless. Any other service provider (ER, plumber, Electrician, auto mechanic) will ALWAYS triage your issues before starting an investigation or fix. You should too.
SQL Tidbit:
When gathering timelines, align your clocks. SQL Server may log in UTC while users report in Central or Eastern time. A “9 AM slowdown” can easily show up in SQL logs at 2 PM. Get this wrong and you’ll chase the wrong evidence.
Thanks for reading!
