The triage method
Purpose: A repeatable diagnostic method for any AEM problem, so debugging is a procedure instead of a mood.
Who this page is for
| Audience | Why it matters to you |
|---|
| All engineers | The meta-skill behind every other page here |
The method
1. DEFINE exact symptom, exact URL/user/instance, since when, how reproducible
2. LOCALISE which layer? (CDN → dispatcher → publish → author) binary-search the chain
which instance? (one publisher or all?) pull LB trick isolates
which content? (one page, one tree, everything?)
3. CORRELATE what changed at symptom-start time: deploys, config, content ops, SP, cert, upstream
4. OBSERVE error.log while reproducing; request in /system/console/requests; thread dumps if slow
5. HYPOTHESISE → TEST cheapest-first; change ONE thing per test
6. FIX + VERIFY same observation that proved the fault now proves the fix
7. WRITE DOWN symptom → cause → fix (runbook or this wiki's model) — pay it forward
Localisation cheat table
| Test | Interpretation |
|---|
| Direct publish URL correct, dispatcher URL wrong | Cache/filter problem (dispatcher) |
| One publisher wrong, others right | Instance drift: replication (queue), deploy skipped it, or local sickness |
| Author right, all publishers wrong | Replication or publish-side ACL (permissions) |
| Wrong for anonymous, right when logged in | ACL/anonymous read gap |
| Wrong with ?nocache-style bypass too | Not a cache problem — stop flushing things |
Discipline notes
- Resist the folk remedies (restart it, reindex it, clear all caches) until localisation says so — they destroy the evidence and usually just reschedule the incident.
- Reproduce before you fix; if you cannot reproduce, you are collecting better observations, not fixing.
- In incidents, stabilise first (incident response); this method then runs on the preserved evidence.