Fishbone diagram for incident analysis: A step-by-step guide

TL;DR: A fishbone diagram maps the contributing causes of an incident across categories, which suits complex production incidents better than the single causal chain of 5 Whys. SRE teams can swap the traditional manufacturing categories for Infrastructure, Code, Configuration, Deployment, Observability, Dependencies, and People. Build it in five steps: write a precise problem statement, add four to six categories, brainstorm causes in each, drill into sub-causes, then turn the top causes into owned follow-up actions. Start from the incident timeline, not memory. incident.io captures that timeline as the incident runs in Slack, and its AI writes the post-mortem's first draft from it.

Latency spikes with contributing causes across a bad deploy, a noisy neighbor, and a missing alert are common in distributed systems, and a single causal chain may not capture all of them. 5 Whys points you toward one root cause, but complex production incidents often call for a method that maps causes across categories.

The traditional fishbone categories come from manufacturing quality control. For SRE teams running microservices on Kubernetes, those categories may not map cleanly. This guide shows you how to rebuild the fishbone around categories like Infrastructure, Code, Configuration, Observability, and Deployment, build it in five steps, run the analysis as a workshop, then connect the diagram to live incident data and post-mortem workflows.

Defining the fishbone diagram for root cause analysis

A fishbone diagram is a visual brainstorming tool that maps causes to an effect. You place the effect at the head of the fish, and cause categories branch off a horizontal spine like ribs. Each branch captures potential causes within that category, and sub-branches capture deeper layers of causation.

The diagram helps because it encourages breadth. Instead of following one thread to a single root cause, you brainstorm across multiple categories at once. This surfaces systemic failures a single causal chain misses, which is critical for distributed systems where failures cascade across services.

Tracing the origins of the Ishikawa diagram

The Ishikawa diagram is named after its creator, the Japanese quality control expert Kaoru Ishikawa. He designed it to help teams identify the many possible causes of a problem and structure their brainstorming. Ishikawa introduced six generic categories, the 6 M's: materials, machinery, methods, measurement, manpower, and mother nature (environment).

He also encouraged creativity in naming the categories so they communicate clearly to the people using them. That is the basis for the SRE categories in this guide. With every potential cause in one view, teams can spot patterns and prioritize investigation.

Choosing fishbone over 5 Whys

5 Whys comes from the Toyota Production System, and critics note it can lead teams to a single root cause. It suits a simple, single-cause incident. For example, a cron job fails because someone deleted a config file during cleanup, and the cleanup script didn't check dependencies. That's a linear chain.

The decision rule: if you can draw the incident as a straight line from cause to effect, use 5 Whys. If you need a map with multiple branches, use a fishbone diagram.

Using Ishikawa diagrams for complex incidents

Distributed systems can suffer cascading failures, where one failing part of the system raises the odds that other parts fail. A single request can cross many services, telemetry is scattered across metrics, logs, and traces, and the first service to page is not always the one that broke. In that environment, root cause analysis means tracing a customer-facing symptom back to a failing service, dependency, or configuration change.

A fishbone diagram captures this reality. Instead of asking "why did the API latency spike?" five times in a row, you ask "what categories of causes contributed?" and then brainstorm within each category. In a multi-factor incident, that can surface a fuller picture: the code change that introduced the bug, the missing observability that delayed detection, the deployment process that didn't catch it in staging, and the infrastructure constraint that amplified the impact.

Capturing multiple contributing factors

Complex outages have multiple contributing causes that interact. A latency spike might start with a code change, but it becomes an incident because a connection pool was misconfigured, an alert threshold was too high, and a dependency service was already degraded. A fishbone diagram puts all of these factors in one view, so you can see how they combined.

The structure also stops the team from fixating on the first plausible cause. You might start with a strong hypothesis, such as a recent deploy, but each empty branch prompts you to check infrastructure, configuration, observability, and external dependencies too.

That breadth is what makes fishbone diagrams valuable for blameless post-mortems. When you map causes across categories, you focus on systemic conditions instead of individual mistakes. The diagram shows that the incident happened because of gaps in process, tooling, and observability, not because one engineer made a bad call.

Timing fishbone analysis after the incident

During an active incident, a quick 5 Whys on the first symptom can guide the next mitigation step. A fishbone diagram needs the full timeline and input from several teams, so it rarely fits mid-incident. For live triage, Investigations, incident.io's AI SRE product, handles the first 80% of incident response by pulling data from alerts, telemetry, code changes, and past incidents.

The fishbone diagram is most valuable after the incident, when you have time to reconstruct the full picture from a structured timeline.

Mapping dependencies in Ishikawa diagrams

Give dependencies their own branch in an SRE fishbone diagram. Third-party APIs, database replicas, and external integrations can all contribute to an incident. Capture causes like "upstream API rate limit hit" or "database replica lag exceeded threshold" that don't fit neatly into Code or Infrastructure.

Mapping dependencies explicitly helps you identify single points of failure and prioritize resilience work. If every incident in the last quarter had a dependency-related contributing cause, that's a signal to invest in circuit breakers, retries, or fallback behavior.

Structuring Ishikawa diagram cause branches

The traditional manufacturing categories don't map cleanly to software incidents, so SRE teams can swap them for categories that reflect how production systems fail. The mapping below is one suggested starting point:

You can also add a branch for Configuration, covering environment variables, secrets, and connection pool or timeout settings.

Analyzing infrastructure causes

Infrastructure causes include node capacity, network partitions, disk I/O saturation, and resource constraints. For SRE teams, these often involve cloud infrastructure: autoscaling limits, noisy neighbors on shared hardware, or regional network issues.

When brainstorming this branch, ask: what infrastructure conditions existed at the time of the incident? Was CPU or memory near capacity? Did a network partition isolate a subset of nodes?

Analyzing build and deployment triggers

Deployment causes include CI/CD pipeline failures, feature flag misconfigurations, and gaps in staging validation. This branch captures causes like "index creation not verified in staging" or "feature flag enabled for 100% of traffic without a canary."

A fishbone diagram helps you ask not just "what code changed?" but "what about our deployment process allowed this to reach production undetected?"

Mapping code changes to root causes

Code causes include recent commits, logic errors, and code defects. This branch tends to fill up fast because recent changes are the most visible suspects in an incident. The fishbone structure pushes you further: not just "a bug in the code," but "what kind of bug, and why did it reach production?"

In the worked example below, the code cause is a missing database index. The deeper causes sit in the process that let the change ship without the index.

Identifying communication gaps in incident response

People causes include communication gaps, unclear ownership, and missing runbooks. This branch captures causes like "on-call engineer didn't know the service owner" or "escalation path wasn't documented."

Communication gaps can turn a minor incident into a major one. If the right people aren't in the room, or if the incident commander doesn't have the context they need, resolution takes longer.

Defining custom branches for your fishbone

Every organization has unique failure modes. If you run a multi-tenant SaaS platform, you might add a Tenant Isolation branch. If you operate in a regulated industry, you might add a Compliance branch. Choose categories that reflect your actual incident history.

Review your last ten post-mortems and identify the common themes. If "missing observability" appears in six of them, make sure Observability is a top-level branch. If "external API degradation" appears in four, make sure Dependencies is a branch.

Building a fishbone diagram step by step

The steps below adapt ASQ's fishbone procedure for software incidents: state the problem, add the cause categories, brainstorm causes in each category, drill into sub-causes, then prioritize follow-ups.

1. Write a precise problem statement

Write a problem statement, not a topic. State the effect precisely, with what happened, where, and how often, and place it at the head of the fish. A vague head produces vague causes.

For example, "API latency spiked to 2,000ms (p99) for 45 minutes, causing 12% of checkout requests to time out" is far more useful than "API was slow." The precision focuses the brainstorm on the specific failure mode.

2. Map out core incident categories

Draw a horizontal spine into the problem and branch your cause categories off it as ribs. Four to six categories keeps the diagram readable. Pick the ones that match your incident types from Infrastructure, Code, Configuration, Deployment, Observability, Dependencies, and People.

Label each branch clearly so participants know where to add causes. If you're running this as a workshop, draw the empty diagram on a whiteboard or shared screen before the session starts.

3. Brainstorm causes in each category

Work through one category at a time and list every plausible cause, including the unlikely ones. The goal is breadth, not depth, at this stage.

Use the incident timeline as your source of truth. What changes did the team deploy in the hours before the incident? Which alerts fired, and which failed to fire? What infrastructure conditions existed? The timeline grounds the brainstorm in facts, not memory.

4. Drill into sub-causes

Ask why again for each cause and add the answers as smaller branches off it. Each new layer shows one cause feeding another. When ideas dry up, go back to the branches with the fewest causes.

For example, if "missing database index" is a cause under Code, a sub-cause might be "schema migration not tested in staging." This is where the fishbone diagram starts to surface systemic issues. A missing index is a code problem, but "schema migration not tested in staging" is a process problem, and "staging environment doesn't replicate production load" is an infrastructure problem.

5. Prioritize actionable follow-ups

Decide which causes need action. Aim each action at a cause, because a fix that only treats the symptom leaves the cause in place.

Prioritize causes that appear across multiple incidents or that represent systemic gaps. If "missing alert on query latency" appears in three post-mortems this quarter, that's a higher priority than a one-off code bug. Convert the top causes into follow-up actions with clear owners and deadlines.

Analyzing an API latency spike with a fishbone

One illustrative walkthrough of a fictional e-commerce platform traces how a single missing database index cascades across services:

1. Inventory queries slowed down.
2. Slow queries held database connections longer and exhausted the connection pool.
3. Inventory requests waited for connections, so the order service waited on inventory.
4. API requests approached their timeout, and the API gateway returned 504 Gateway Timeouts.

Mapping the API latency sequence

The latency incident started with a code change: a migration added a column and changed the query pattern, but the matching index was never created. The slow query didn't trigger a deployment failure, so nothing stopped it from reaching production.

Each event in the chain maps to a fishbone branch:

• Code: The migration changed the query pattern without the matching index.
• Deployment: No automated query-plan check ran before release.
• Observability: The early inventory warning paged nobody.
• Configuration: The connection pool ran out once slow queries held connections longer.
• Dependencies: The order service called inventory synchronously, so inventory delays became order delays.

Turning the fishbone into follow-ups

The fishbone for the API latency incident shows it wasn't just a code bug. It was a code bug that reached production because of a deployment process gap, became an incident because of an observability gap, and cascaded once the connection pool ran out of capacity. The follow-up actions include: add the missing index (Code), add pre-flight checks for schema migrations (Deployment), add alerts on query latency and connection pool saturation (Observability), and audit connection pool sizing for peak load (Configuration).

This is the value of the fishbone structure: it pushes you to address the systemic conditions, not just the immediate cause. A 5 Whys chain follows one thread, so it can trace the missing index back to the deployment gap but tends to skip the alerting and pool sizing causes on other branches. The fishbone diagram surfaces all three additional fixes in one view.

Leading a fishbone root cause workshop

A fishbone diagram works best as a collaborative exercise. The diagram itself is valuable, but the conversation it structures is where the learning happens. Here's how to run a blameless fishbone workshop that surfaces systemic causes without pointing fingers.

Choosing your incident analysis team

Include the incident commander, the on-call engineer who responded, and representatives from the teams that own the affected services. If the incident involved a third-party dependency, include someone who understands that integration. Keep the group small enough to have a conversation but large enough to capture different perspectives.

Keeping your fishbone session focused

Set a time limit, such as 60 to 90 minutes, and a clear scope (the specific incident, not a general discussion of reliability). Start with the problem statement and the empty fishbone structure, then work through each category systematically.

If the conversation drifts into solutions, redirect it. The goal of this session is to map causes, not to design fixes. Capture solution ideas in a parking lot and address them in a follow-up session.

Conducting incident analysis safely

Google's SRE Book sets the standard: a blameless post-mortem identifies the contributing causes of an incident without indicting any individual or team for bad or inappropriate behavior.

When someone says "they should have caught that in review," redirect: "What about our process made it possible for this to reach production?" Redirect phrases that work: "What about the system allowed this?" "What information was missing at the time?" "If we assume everyone made reasonable decisions, what was the gap?"

Describe who was involved and what they did, then keep asking why until you reach the system condition that made those actions reasonable at the time. If you stop earlier, the post-mortem records what happened but not why the system allowed it.

Choosing digital tools for Ishikawa diagrams

You can draw a fishbone diagram on a whiteboard, but digital tools make it easier to collaborate remotely and link causes to evidence. The challenge is that static diagrams in Miro or Lucidchart feel disconnected from the live incident data in Datadog, Slack, and PagerDuty.

Starting from a standard fishbone template

Start with a fishbone template that includes the SRE categories pre-labeled. This saves time and keeps post-mortems consistent. Choose a tool your team already uses: if your team lives in Figma, build a fishbone template there. If you use Miro for post-mortem workshops, use Miro for fishbone diagrams.

Common diagramming platforms offer ready-made options, including Miro's fishbone templates, Lucid's fishbone template, and Creately's fishbone template.

Feeding the fishbone from a captured timeline

The fishbone diagram you build during analysis is only as good as the data you feed it. If you're reconstructing the incident from memory and Slack scroll-back, you'll miss causes.

incident.io builds the timeline in real time as the incident happens. Severity and status changes and pinned Slack messages land on the timeline automatically, and responders can add role changes, actions, and other detected events from the incident activity log. On resolution via /inc resolve, the timeline is already built and ready to feed the fishbone.

Linking fishbone diagrams to post-mortems

The fishbone diagram's value extends beyond the workshop. Once the incident is resolved, you create the post-mortem. On the Pro and Enterprise plans, incident.io's AI writes a first draft from the timeline, the incident channel conversation, and custom fields, so you start from a draft instead of a blank page. The post-mortem meeting can then focus on the root cause and action items.

You can upload the fishbone diagram as an image in the post-mortem editor and reference timeline timestamps next to the causes they support. This creates a single source of truth for the incident analysis, which makes it easier to share learnings and track follow-up actions.

With auto-export set up, incident.io sends each follow-up to your issue tracker, such as Jira or Linear, using a template that sets the project, owner, and labels. Owners are notified when assigned, and you can send reminders on open follow-ups from the dashboard. The fishbone findings end up in the task tracker your team already works from.

Book a demo of incident.io and see how timeline capture and AI-drafted post-mortems give your next fishbone session a head start.

Key terms glossary

Fishbone diagram: A visual brainstorming tool that maps causes to an effect, with cause categories branching off a horizontal spine like ribs. It is also called an Ishikawa diagram or cause and effect diagram.

5 Whys: A root cause analysis method that works by repeatedly asking "why?", conventionally about five times, to trace a problem toward its root cause. It works well for simple, single-cause incidents but can miss multi-factor failures.

Blameless post-mortem: A post-incident review that aims to identify systemic contributing causes without blaming individuals. The goal is to learn and improve, not to assign fault.

Timeline capture: The automatic recording of incident events (severity and status changes, pinned messages) as the incident unfolds. It removes most of the work of reconstructing the timeline from memory afterward.

SRE categories: Cause categories that SRE teams can use in place of the traditional manufacturing categories in a fishbone diagram for software incidents. Teams adapt categories like Infrastructure, Code, Configuration, Observability, Deployment, Dependencies, and People to fit their own failure modes.

Root cause analysis (RCA): The process of tracing an incident back to the underlying causes across code, infrastructure, configuration, and process. SRE teams use RCA to prevent recurrence, not just restore service.