Skip to content
Back to skills

Fmea

ASecurity

Systematically identify potential failure modes, assess their severity and likelihood, and prioritize preventive actions using risk priority numbers

  • 22 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 20, 2026
businessrustgoapidatabaseperformance

Works with

  • cli
  • api

Security analysis

A100/100

Scanned September 20, 2026

npx -y skills add lev-os/agents --skill fmea --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Fmea?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Fmea
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/lev-os-fmea/badge)](https://www.skillsdirectory.com/skills/lev-os-fmea)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: fmea
description: Systematically identify potential failure modes, assess their severity and likelihood, and prioritize preventive actions using risk priority numbers
---

# FMEA (Failure Mode Effects Analysis)

## Overview
FMEA is a systematic, proactive method for evaluating processes to identify where and how they might fail and assessing the relative impact of different failures. Developed in aerospace/automotive industries, FMEA calculates Risk Priority Numbers (RPN = Severity × Occurrence × Detection) to prioritize which failures to prevent first.

## When to Use
- Designing new products, processes, or systems
- Launching critical features with high failure cost
- Incident post-mortems to prevent recurrence
- Evaluating vendor/supplier reliability
- Improving manufacturing quality
- Pre-launch risk assessment

## The Process

### Step 1: Identify Potential Failure Modes
List all ways the system could fail. For each component/process step, ask: "What could go wrong?"

**Example:** E-commerce checkout process failure modes: payment gateway timeout, inventory out of sync, address validation fails, credit card decline, email confirmation fails.

### Step 2: Assess Severity (1-10 Scale)
Rate impact if failure occurs. 1 = no impact, 10 = catastrophic. Focus on customer/business impact, not technical complexity.

**Example:** Payment gateway timeout: Severity = 9 (lost revenue, customer frustration). Email confirmation fails: Severity = 3 (inconvenient but order proceeds).

### Step 3: Assess Occurrence (1-10 Scale)
Rate likelihood of failure happening. 1 = rare, 10 = inevitable. Base on data if available, educated guess if not.

**Example:** Payment timeout: Occurrence = 2 (gateway 99.5% uptime). Email fails: Occurrence = 4 (email service less reliable).

### Step 4: Assess Detection (1-10 Scale)
Rate likelihood of catching failure before customer impact. 1 = always detected, 10 = never detected until customer complains.

**Example:** Payment timeout: Detection = 3 (monitoring alerts immediately). Email fails: Detection = 8 (no monitoring, customer must report).

### Step 5: Calculate RPN and Prioritize
RPN = Severity × Occurrence × Detection. Higher RPN = higher priority. Focus mitigations on highest RPNs first.

**Example:**
- Payment timeout: 9 × 2 × 3 = 54 RPN
- Email fails: 3 × 4 × 8 = 96 RPN → Prioritize email monitoring despite lower severity

### Step 6: Implement Actions and Reassess
Design mitigations to reduce Severity (safer failure mode), Occurrence (prevent failure), or Detection (catch earlier). Recalculate RPN after mitigation.

**Example:** Add email delivery monitoring (Detection 8 → 2). New RPN: 3 × 4 × 2 = 24 (acceptable).

## Example Application

**Situation:** SaaS company launching new API with high-value enterprise customers.

**Failure Modes Analysis**:
1. API returns 500 errors: S=10, O=3, D=2 → RPN=60
2. Response time >5sec: S=7, O=5, D=4 → RPN=140
3. Authentication fails: S=9, O=2, D=3 → RPN=54
4. Rate limiting blocks requests: S=8, O=6, D=7 → RPN=336

**Prioritization**: Address rate limiting first (RPN=336), then response time (RPN=140).

**Mitigations**:
- Rate limiting: Per-customer limits (O: 6→2), monitoring alerts (D: 7→2) → New RPN=32
- Response time: Database indexing (O: 5→2), performance monitoring (D: 4→1) → New RPN=14

**Outcome:** Launch succeeds, no customer-facing failures. Prevented potential churn.

## Anti-Patterns
- ❌ Skipping low-severity, high-occurrence issues (death by a thousand cuts)
- ❌ Rating based on technical complexity vs. customer impact
- ❌ Ignoring detection rating (undetected failures multiply impact)
- ❌ Treating FMEA as one-time exercise vs. living document
- ❌ Analysis paralysis (don't FMEA every trivial process)
- ❌ Confusing RPN with absolute risk (RPN is relative prioritization tool)

## Related
- five-whys
- fishbone-diagram
- root-cause-analysis
- risk-management
- pre-mortem

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…