Glossary · Monitoring

Five Whys

Five Whys is a root-cause technique that asks "why" repeatedly, typically around five times, to trace a problem from its symptom to a fixable underlying cause.

Updated November 11, 2026

Five Whys is a simple analysis method in which you state a problem, ask why it happened, then ask why about each answer until you reach a cause you can act on. Five is a rule of thumb, not a requirement.

Why it matters

Incidents are usually closed with the first cause found, such as "the disk filled up", which invites a one-off fix. Asking again exposes the process gap behind it, such as missing alerts or no log rotation. Used in a blameless postmortem it keeps attention on systems and decisions, not on whoever pressed the button. Its weakness is that it follows a single chain, though real failures often have several contributing causes.

Example

The site was down for 40 minutes. Why?
 1. The database refused connections. Why?
 2. Disk was full. Why?
 3. Slow-query logs grew without limit. Why?
 4. Log rotation was never configured on the new server. Why?
 5. The server was built by hand, not from the standard template.

Fix actions: rotate logs, alert at 80% disk, and build servers from the template.

Common mistakes

  • Stopping at a person ("operator error") instead of the process that allowed it.
  • Following only one chain when several factors contributed.
  • Producing actions with no owner or date.

Get notified when this term updates

Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.

Keep reading

Glossary · MonitoringIncidentAn incident is an unplanned event that disrupts or degrades a service and requires a coordinated response to restore normal operation.Glossary · MonitoringIncident CommanderThe incident commander is the person who coordinates the response to a major incident, assigning tasks and decisions while others fix the problem.Glossary · MonitoringMTTR (Mean Time to Recovery)MTTR is the average time it takes to restore service after an incident, measured from failure start to recovery; the letter R is used for several meanings.Guide · MonitoringAlert Fatigue and On-Call Basics for Small TeamsSet severity levels, escalation paths, alert thresholds and runbooks so a small team gets paged for real problems only and still sleeps through the night.8 min readGuide · MonitoringA Blameless Incident Postmortem Template With a Worked ExampleWrite a blameless incident postmortem that drives real fixes: timeline, root cause vs contributing factors, 5 whys limits, a copy-paste template and an example.10 min readGuide · MonitoringSLA Uptime Calculation: Exclusions, Credits and How to Write OneHow hosting providers calculate SLA uptime, what exclusions and service credits mean in practice, and how agencies should word an SLA they can actually meet.7 min read

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.