Website Outage Logic Tree

Website outage logic tree

This logic tree helps an on-call engineer narrow a website outage without jumping straight to a single suspected cause. It separates reachability from application health. DNS failure, load-balancer failure, and an unhealthy application require different evidence and different owners. Once the basic checks pass, traffic spikes and upstream dependencies become plausible causes. The leaves are deliberately phrased as checks rather than diagnoses, because incident work should follow current evidence. Adapt the labels to the actual architecture and link each leaf to a runbook. A logic tree is useful when several causes can produce the same symptom. It gives readers a concise reference they can reuse when discussing the result with colleagues.

유형 의사결정 트리표준 Howard-Raiffa / CART-sklearn / taxonomy엔진 schematex-decisiontree업데이트됨 2026. 9. 24.

요청 내용

“A logic tree for a website outage: split into reachability and application checks, then include DNS, load balancer, health checks, traffic, deployments, logs, and database connectivity.”

그렇다면Add a branch for expired TLS certificatesAdd a cache and CDN check

이 도면에 담긴 내용

그 이면의 의사결정을 읽어 보세요.

01Reachability

Establish whether users can resolve and reach the service.

02Health

Separate infrastructure reachability from application health.

03Evidence

Use monitoring and logs at each leaf.

Use as a first-pass on-call troubleshooting guide for a web service.

모든 의사결정 트리 템플릿 보기 →

자주 묻는 질문

Why check DNS first?

A DNS problem can prevent users from reaching an otherwise healthy service.

Are branches always exclusive?

Not always; use evidence to identify which hypotheses need testing.

What belongs at a leaf?

A test, observation, or next diagnostic action.