Mental Model: OODA Loop¶
Category: Operational Reasoning Origin: Colonel John Boyd, USAF — developed in the 1970s to describe fighter pilot decision-making; later generalized to all competitive and crisis environments One-liner: Observe, Orient, Decide, Act — the faster you cycle through this loop, the more control you have over an unfolding situation.
The Model¶
The OODA Loop describes the four-stage cognitive cycle that any actor — human, team, or organization — must complete to respond to a changing environment. The model was originally designed to explain how fighter pilots win dogfights: the pilot who can cycle through the loop faster forces their opponent to react to a reality that has already changed, eventually causing the opponent's decision-making to collapse.
In incident response, the OODA loop maps almost perfectly. A production outage is an adversarial environment — not against a human enemy, but against a system in an unexpected state. Your goal is to cycle through Observe → Orient → Decide → Act faster than the system degrades further, faster than customer impact compounds, and faster than your mental model of what is happening drifts from reality.
Observe means gathering raw data without interpretation: metrics, logs, traces, alerts, error messages, user reports. The quality of your observations sets a hard ceiling on everything downstream. Missing a key signal here means you are orienting around an incomplete picture. In practice: cast a wide net first, then focus.
Orient is the hardest and most important step, and it is where Boyd spent most of his intellectual energy. Orientation means synthesizing raw observations into a mental model of the situation — filtering noise, applying past experience, running hypotheses, and building a picture of what is probably happening. Your mental models, biases, training, and cultural filters all shape orientation. This is why experienced engineers orient faster: they pattern-match against a larger library of past incidents. This is also where incorrect priors cause expensive wrong turns — you "see" a memory leak because you just fixed one, even when the data says otherwise.
Decide is selecting one action from the available options your orientation has generated. Under pressure, this step often collapses to gut feel, which is fine — provided orientation was accurate. The mistake is spending too long deciding when the situation demands action; analysis paralysis is a OODA loop that stalls between Decide and Act.
Act is executing the decision and then immediately looping back to Observe — because the system's state has changed as a result of your action, and your model must update accordingly. A command is run, a rollback is initiated, a service is restarted — and then you watch what happens next. The loop is continuous, not linear.
Visual¶
┌────────────────────────────────────────┐
│ ENVIRONMENT │
│ (production system, incident state) │
└────────────┬───────────────┬───────────┘
│ signals │ affected by
▼ │
┌──────────────────┐ │
│ OBSERVE │ │
│ metrics, logs, │ │
│ traces, alerts │ │
└────────┬─────────┘ │
│ │
▼ │
┌──────────────────┐ │
│ ORIENT │ │
│ mental models, │ │
│ past incidents, │ │
│ hypothesis gen │◄───────┤
└────────┬─────────┘ loop │
│ │
▼ │
┌──────────────────┐ │
│ DECIDE │ │
│ pick one action │ │
│ from options │ │
└────────┬─────────┘ │
│ │
▼ │
┌──────────────────┐ │
│ ACT │────────┘
│ execute, then │ (changes environment,
│ immediately │ loop restarts)
│ re-observe │
└──────────────────┘
MTTR impact by loop speed:
Slow OODA (10 min/cycle): 3 cycles = 30 min before effective action
Fast OODA (2 min/cycle): 3 cycles = 6 min before effective action
flowchart TD
ENV["Environment\n(production system, incident state)"]
OBS["Observe\nmetrics, logs, traces, alerts"]
ORI["Orient\nmental models, past incidents,\nhypothesis generation"]
DEC["Decide\npick one action from options"]
ACT["Act\nexecute, then re-observe"]
ENV -->|signals| OBS
OBS --> ORI
ORI --> DEC
DEC --> ACT
ACT -->|changes environment| ENVWhen to Reach for This¶
- During active incident response, to ask: "Where in the loop are we stuck?" and unblock the team
- When reviewing postmortems to identify where the OODA cycle broke down — missed signals (Observe), wrong hypothesis (Orient), decision paralysis (Decide), or insufficient execution speed (Act)
- When designing on-call processes: runbooks shorten the Decide phase, good dashboards strengthen the Observe phase, blameless culture accelerates Orient by making engineers share uncertain hypotheses without fear
- When onboarding new engineers to incident response — the loop gives them a mental scaffold for chaotic situations
- When an incident drags on without resolution: ask explicitly "what is our current orientation, and what would falsify it?"
When NOT to Use This¶
- Do not use it to pressure engineers into faster decisions when the correct next step is genuinely unknown — fast bad decisions cycle faster than slow good ones, but still produce bad outcomes
- Avoid treating OODA as a checklist to step through sequentially during calm, non-incident work; it is a model for decision-making under time pressure and uncertainty, not routine change management
- Do not confuse loop speed with loop quality: a team cycling the loop quickly around the wrong hypothesis will act confidently in the wrong direction; Orient accuracy matters more than raw cycle speed
Applied Examples¶
Example 1: Kubernetes pod crashlooping with no logs¶
An alert fires at 03:00: deployment/payment-api has 0/3 pods ready. On-call engineer opens the incident.
Observe: kubectl get pods shows all pods in CrashLoopBackOff. kubectl logs <pod> returns empty — the container is crashing before writing to stdout. kubectl describe pod shows OOMKilled in last state. Prometheus shows memory usage spiking to limit in the last 5 minutes.
Orient: OOMKilled + no logs + recent deploy 2 hours ago. Hypothesis: the new image has a memory regression. Secondary hypothesis: a traffic spike is causing legitimate memory pressure. Orient toward the deploy because timing correlates.
Decide: Roll back the deployment to the previous image tag. Do not increase memory limits yet — that would treat the symptom, not the cause.
Act: kubectl rollout undo deployment/payment-api. Then immediately re-Observe: pods start successfully, memory stabilizes, error rate drops. Loop closes. MTTR: 11 minutes.
Without the OODA frame, a junior engineer might have spent 20 minutes trying to get logs from a crashing container, or escalated before attempting rollback, because there was no structure for moving from observation to action.
Example 2: Database connection pool exhaustion during peak traffic¶
Observe: Alert fires — p99 latency on the API is 8 seconds, up from 200ms. Database slow query log shows nothing unusual. Connection pool metrics show all 100 connections in use. Incoming request queue growing.
Orient: Full connection pool is the constraint. Two hypotheses: (a) a query is holding connections longer than normal, or (b) traffic volume genuinely exceeds connection capacity. Check traffic graphs — RPS is 40% above baseline. Check connection hold duration — average is 2.1s, was 0.3s this morning. A slow query is the upstream cause.
Decide: Kill long-running queries to free connections immediately; investigate query cause in parallel as a second loop.
Act: SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE duration > '5 seconds'. Re-observe: connection count drops, latency recovers to 600ms, still degraded. Second OODA cycle begins on why queries slowed — missing index on new column added in today's migration.
The Junior vs Senior Gap¶
| Junior | Senior |
|---|---|
| Jumps straight to Act (restarts the service) without completing Observe or Orient | Spends 60–90 seconds in Observe before touching anything, to avoid making the situation worse |
| Orients around the first hypothesis and stops gathering data | Holds multiple competing hypotheses simultaneously and seeks data that distinguishes between them |
| Treats each observation as independent; struggles to synthesize a picture | Recognizes patterns from past incidents during Orient, dramatically shortening time-to-correct-hypothesis |
| Stalls in Decide, waiting for certainty that never comes | Decides when evidence is sufficient, not when it is complete — accepts residual uncertainty |
| Acts once and assumes the incident is resolved | Acts and immediately re-enters Observe; treats each action as an experiment |
| MTTR is dominated by Orient thrash — trying the same wrong fix multiple times | MTTR is dominated by Orient depth — accurate mental model on the first or second cycle |
Connections¶
- Complements: Runbook-Driven Recovery (runbooks pre-cache the Decide phase — when Orient produces a known pattern, the decision is already written down)
- Complements: Blameless Postmortem (postmortems are structured OODA retrospectives — they identify exactly which phase broke down and why, so the next loop runs faster)
- Tensions: Analysis Paralysis (the failure mode of over-investing in Orient at the expense of Act; OODA explicitly requires moving forward on incomplete information)
- Topic Packs: incident-management
- Case Studies: crashloopbackoff-no-logs (Orient phase failure: no logs forced the engineer to reason from container state alone), systemd-service-flapping (repeated OODA cycles as each Act produced new Observe data that contradicted the prior hypothesis)