The Repeatable Framework

1❓ Understand the Problem

Before changing anything, establish exactly what the problem is. Ask: what is failing? What should normally happen? What happens instead? When did it begin? Is it constant or intermittent? Can it be reproduced? What error appears? Which systems, users, locations, devices and applications are affected?

2📏 Determine the Scope

Scope is one of the fastest ways to narrow a problem down. One user or many? One computer or many? One office or multiple regions? One server or the whole cluster? One application or several? Internal or external users? Production only, or dev and production? One browser, OS, network, identity provider, or cloud region?

If one user can't reach Microsoft 365 but everyone else can, the issue is likely their account, session, device, licence, or network. If 40,000 users suddenly can't authenticate, the odds that all 40,000 individually broke their own accounts at the same moment are essentially zero — the investigation should shift immediately toward shared infrastructure instead.

3⏳ Last Known Good State & What Changed

One of the most useful troubleshooting questions is simply: when did this last work? Suppose the application worked at 09:00, a deployment happened at 09:30, and errors began at 09:35 — the deployment immediately becomes relevant. This doesn't prove it caused the incident, but it gives you a strong starting hypothesis. Engineers call this the Last Known Good configuration.

Many production incidents happen because something changed: a software deployment, an OS update, a firewall rule, a certificate renewal, a password rotation, a DNS modification, a Group Policy update, a Conditional Access policy, an IAM role change, a load balancer configuration, a cloud security group, an application release, an antivirus update, a routing change, a firmware upgrade, an API change, or a third-party service change. Large organisations track these through formal Change Management platforms — ServiceNow, Jira Service Management, BMC Helix, and similar tools — and during an incident, reviewing recent changes is usually one of the very first things worth doing.

4🔄 Reproduce the Problem & Capture the Exact Error

If possible, reproduce the issue yourself rather than trusting a secondhand description. A user says "login doesn't work" — instead of immediately resetting their password, walk through the login flow and observe exactly where it breaks: username entered, password accepted, MFA challenge displayed, push approved, browser redirected, application returns HTTP 403. That last step reframes the whole problem — this isn't an authentication failure at all, it's an authorisation one, and that distinction changes everything about where you look next.

Never record "it gave an error." Record the exact error: HTTP 401 Unauthorized, javax.net.ssl.SSLHandshakeException, DNS_PROBE_FINISHED_NXDOMAIN, or "The trust relationship between this workstation and the primary domain failed." Copy error messages verbatim, capture screenshots, and record timestamps, request IDs, correlation IDs, session IDs, usernames where permitted, and affected system names — every one of those can later be correlated with server logs (Module 14's correlation-ID technique applies directly here).

5🕑 Build a Timeline

Complex incidents deserve a timeline, not a paragraph of prose:

09:00 Application healthy
09:15 Certificate deployment started
09:18 Load balancer configuration updated
09:21 First TLS errors recorded
09:24 Customer complaints begin
09:27 Monitoring alert triggered
09:32 Incident declared
09:40 Certificate rollback performed
09:43 Service restored

A timeline can reveal relationships that aren't obvious any other way — here, the certificate deployment at 09:15 sits suspiciously close to the first TLS errors at 09:21, three minutes before anyone even noticed. This technique is particularly valuable for cyber incidents, major outages, authentication failures, cloud incidents, database problems, performance problems, and security investigations alike (Module 12's incident-response timeline and Module 14's log-correlation timeline are both this exact same skill, applied to different evidence).

Lesson Outcome

You should now be able to turn a vague complaint into a precise problem statement, use scope to narrow an investigation fast, identify the last known good state and ask what changed, reproduce a problem yourself and capture the exact error rather than a paraphrase, and build a timeline that makes relationships between events visible. Lesson 2 covers the systematic techniques you apply once you've gathered this initial picture — layers, hypotheses, and controlled changes.