A playbook for building your own personal, incident-ready troubleshooting checklist — a concrete template plus the reasoning for why a checklist beats relying on memory under pressure.
The goal here isn't to memorize a generic checklist someone else wrote — it's to build your own, based on the systems you actually support, so that during a real incident (when stress makes it harder to think clearly) you have a concrete first move instead of a blank page. Have ready: a list of the 2-4 systems or services you're responsible for supporting most often.
List your most common incident types from memory first. Before looking anything up, write down the 5-10 kinds of problems you've personally dealt with most often in the last few months (e.g., "site returns 502," "scheduled job didn't run," "user can't log in").
For each type, write the first three checks you'd actually run, in order — not everything you could check, just the first three that would tell you the most, fastest. Use the diagnostic-steps structure from Isolating "Is It the Network or the App?" as a model: start broad (is it reachable at all), then narrow (which specific layer).
Write the exact command for each check, not just a description. "Check if the app pool is running" is less useful under pressure than the actual PowerShell or IIS Manager steps to check it right now. Copy exact commands from the relevant guides in this archive rather than re-deriving them from memory during an actual incident.
Add an escalation trigger for each incident type — a specific condition under which you stop investigating alone and bring someone else in (a time limit, a specific finding, or a severity threshold). Deciding this in advance, calmly, is far better than deciding it in the middle of a stressful incident.
Store the checklist somewhere you'll actually open it during an incident — not buried in a folder you forget exists. A single page, bookmarked or pinned, beats a comprehensive document nobody opens under pressure.
Revisit and update it after every real incident. The single highest-value moment to update this checklist is right after a real incident, while the specific gap (a check you didn't think to run, a command you had to search for) is still fresh.
A good personal checklist is a living document, not a one-time artifact — the habit of updating it pairs directly with Root Cause Analysis: A Simple Framework, since every root cause you find is a candidate for a new checklist entry.
Part of: Support Engineers
A practical, repeatable framework for finding a real root cause instead of stopping at the first plausible explanation — the Five Whys, contributing-vs-root-cause, and writing a blame-free postmortem.
A step-by-step method for isolating whether a slow or failing request is a network problem, a proxy/load-balancer problem, or an application problem — before you start reading application logs.