fatigue-and-stress-cycling

Analyze cumulative failure risk from repeated sub-threshold stress in long-lived systems.

2|Updated Apr 30, 2026
One-click install
npx skills add https://github.com/NlightNFotis/skills --skill fatigue-and-stress-cycling
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fatigue-and-stress-cycling
Source: https://github.com/NlightNFotis/skills/tree/main/fatigue-and-stress-cycling
Command: npx skills add https://github.com/NlightNFotis/skills --skill fatigue-and-stress-cycling

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you diagnose and prevent failures caused by repeated low-level stress rather than a single obvious overload. It is especially useful when a system has worked reliably for months or years, then suddenly fails without a clear trigger, while earlier warning signs were dismissed as harmless noise.

Core Features & Use Cases

  • Fatigue-based incident analysis: Separates one-time overload events from cumulative damage caused by many routine cycles.
  • Cycle and stress mapping: Identifies stress concentrators, defines cycle profiles, and estimates fatigue life using repeated-load thinking.
  • Preventive treatment planning: Recommends mitigation such as smoothing spikes, lowering baseline load, removing bottlenecks, and scheduling inspection or replacement intervals.
  • Use cases: Investigating intermittent retries that keep self-healing, reviewing long-lived connection pools or caches, planning maintenance for aging infrastructure, and assessing burnout risk in on-call rotations.

Quick Start

Ask the fatigue-and-stress-cycling skill to analyze a long-running component that recently failed after intermittent self-healing warnings and estimate its likely fatigue pattern, stress concentrators, and replacement cadence.

Frequently Asked Questions about fatigue-and-stress-cycling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why does a long-running system suddenly fail without a clear trigger after months of reliability?

Sudden failures in long-running systems often stem from fatigue caused by accumulated damage from repeated sub-threshold stress, rather than a single overload event. Dismissed intermittent self-healing errors act as micro-symptoms of this cumulative risk.

How do I diagnose intermittent connection pool or cache failures that keep self-healing?

Diagnose intermittent connection pool or cache failures by mapping stress concentrators, defining cycle profiles, and estimating fatigue life using repeated-load thinking. This distinguishes cumulative damage from routine cycles and identifies the underlying stress causing the self-healing errors.

What is the difference between single-event overload and cumulative fatigue in incident analysis?

Cumulative fatigue in incident analysis is caused by many routine cycles of low-level stress accumulating damage over time, whereas a single-event overload is a distinct, obvious trigger. Identifying accumulated cycle counts separates these failure modes.

How do I estimate replacement or inspection intervals for aging infrastructure components?

Estimate replacement or inspection intervals for aging infrastructure by identifying stress concentrators and accumulated cycle counts, then calculating the fatigue life. This preventive treatment planning schedules maintenance before cumulative damage causes a critical failure.

Can fatigue and stress cycling analysis assess burnout risk in on-call rotations?

Yes, fatigue and stress cycling analysis assesses on-call burnout risk by treating repeated low-level operational stress as cumulative damage. It identifies stress concentrators in rotation schedules and estimates fatigue life to recommend preventive mitigation.

What are the limitations of using stress concentrator mapping for capacity planning?

Stress concentrator mapping for capacity planning requires accurate identification of accumulated cycle counts and micro-symptoms. It is less effective for diagnosing sudden, single-event overload failures and works best for long-lived systems with intermittent self-healing errors.