The Technology Diagnostics Playbook

1. Observe — capture the symptom precisely (URL, time, region, user, error).
2. Hypothesize — what's the cheapest test that would prove or disprove a likely cause?
3. Test — run it, record the result.
4. Decide — is the hypothesis confirmed, ruled out, or inconclusive?
5. Repeat until the root cause is isolated.

When multiple things break at once: triage by blast radius first (how many users affected), then by reversibility (a failed deploy you can roll back is lower priority than data corruption that's spreading), then by stakeholder visibility. Communicate priority decisions explicitly so the team isn't fighting over what's next.

1. Confirm the destination is reachable (ping, server status).
2. Trace the route to find which hop introduces problems.
3. Check DNS — many "network" problems are name-resolution problems.
4. Measure packet loss and jitter on the affected path.
5. Compare from a known-good network to isolate local vs upstream.

1. Uptime check from multiple regions — is it down for everyone or just some?
2. SSL and DNS validation — most surprise outages live here.
3. Origin response time and status — does the server respond and how fast?
4. Front-end audit — is the page rendering slowly or breaking client-side?
5. Recent changes — what shipped in the last 24 hours?

1. Verify health checks across all components in the dependency graph.
2. Inspect logs and metrics for the affected service and its immediate dependencies.
3. Check provider status pages and recent maintenance windows.
4. Test failover paths — does the redundancy you paid for actually work?
5. Document the timeline as you go for the post-mortem.