cloudparts

LitmusChaos

A chaos engineering platform for Kubernetes with a web control plane, ChaosCenter, that designs, schedules and scores experiments, and an execution plane of operators and Kubernetes custom resources that runs the faults in target clusters.

CNCF · Incubating
What it is
Chaos engineering
Type
Open source
Made by
Cloud Native Computing Foundation
Foundation
Cloud Native Computing Foundation, incubating, joined June 2020. Part of the Linux Foundation
License
Apache 2.0
Facts checked
24 October 2026
Website Source code

What it is

Litmus splits into a control plane and an execution plane. The control plane is ChaosCenter, a web portal and API where you build chaos experiments from faults, schedule them and look at the results. The execution plane, called a chaos infrastructure since 3.0, is a set of agents and operators installed in each target Kubernetes cluster, either the one ChaosCenter runs in or a remote one. It turns an experiment into Kubernetes custom resources and runs them.

Three resources sit at the core. A ChaosExperiment is an installable template for one fault, such as pod deletion or CPU hog, with its permissions and defaults; ready-made ones are shared on ChaosHub. A ChaosEngine links a fault to a target workload and sets how it runs, and the chaos operator acts on it. A ChaosResult records the verdict, which a chaos exporter publishes as Prometheus metrics. The steady-state hypothesis is written as probes: an HTTP check, a shell command, a Kubernetes resource check or a PromQL query, run before, after or throughout the fault. A fault passes only if every probe passes.

Why teams pick it

  • Probes put the steady-state hypothesis into the experiment itself, so each run ends with a pass or fail verdict instead of someone reading graphs
  • One ChaosCenter can drive chaos infrastructures in many clusters, with a library of ready-made faults on ChaosHub
  • Fits pipelines: results become Prometheus metrics, and experiments can be triggered through GitOps as a CI/CD stage
  • CNCF incubating project with steady releases (3.33.0 in October 2026), and a commercial version, Harness Chaos Engineering, from its main sponsor

Watch out for

  • More moving parts than a single operator: ChaosCenter needs its own database (MongoDB) as well as the agents in each cluster
  • 3.0 renamed its core terms (agents became chaos infrastructures, workflows became experiments, experiments became faults) and isn’t backward compatible with older ChaosCenter releases
  • Faults run with broad Kubernetes permissions, and late-2025 releases fixed security issues including a namespace escape through hostPID
  • Kubernetes first: other targets such as cloud resources and VMs are reached through specific faults rather than a general agent

Alternatives

What all chaos engineering have in common →Compare side by side →
Chaos MeshOpen sourceA chaos engineering platform for Kubernetes: you describe a fault such as a killed pod, network latency or clock skew as a custom resource, and a privileged daemon on each node injects it and takes it away again.

How it fits with other technologies

A ChaosEngine that runs the pod-cpu-hog fault against an nginx deployment for 60 seconds · yaml

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-cpu-hog
  namespace: litmus
spec:
  engineState: active
  appinfo:
    appns: default
    applabel: run=nginx
    appkind: deployment
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-cpu-hog
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: '60'
            - name: CPU_CORES
              value: '1'
            - name: PODS_AFFECTED_PERC
              value: '100'

See it in a real stack

No architecture uses LitmusChaos yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2017–2025

Litmus started in 2017 at MayaData, the company behind the OpenEBS storage project, as a way to run simple chaos jobs in Kubernetes. MayaData co-founder Uma Mukkara later said that “what started as our own tooling for user success has evolved into an active community”. The CNCF accepted LitmusChaos into its Sandbox in June 2020.

Litmus 2.0, released in August 2021, improved scalability, testing against steady-state hypotheses and Prometheus metrics, around ChaosCenter, a central control plane for many target environments. ChaosNative, the company formed around Litmus with Mukkara as CEO, saw the project promoted to CNCF Incubating on January 11, 2022, and was bought by Harness on March 22, 2022; Harness built its Chaos Engineering module on Litmus and became the project’s main sponsor.

Litmus 3.0 reached general availability in November 2023 with reusable probes, environments for grouping chaos infrastructures, a visual experiment builder and new names for its core objects. Releases have continued monthly; late-2025 versions concentrated on security fixes, and an MCP server for AI assistants appeared in October 2025.

Why it’s built this way

Chaos as Kubernetes custom resources
Declaring the fault and the steady-state hypothesis as resources lets the platform run as ordinary microservices and operators, and lets users manage experiments with the same tools as the rest of the cluster.
A separate control plane and execution plane
Splitting ChaosCenter from the per-cluster agents lets one portal schedule and compare experiments across many clusters, and lets results flow back for scoring and dashboards.
Bring your own chaos
A ChaosExperiment is only a template that names the library doing the injection, so third-party tools can be plugged in, and vendors can publish their own experiments on ChaosHub.

Timeline

  1. 2017

    Litmus starts at MayaData as simple chaos jobs for Kubernetes

  2. 2020

    Accepted into the CNCF Sandbox in June

  3. 2021

    Litmus 2.0 in August

  4. 2022

    CNCF Incubating in January; Harness acquires ChaosNative in March

  5. 2023

    Litmus 3.0 reaches general availability in November

  6. 2025

    MCP server released; security-focused 3.22 and 3.23 releases

Sources9 · facts checked 24 October 2026

Improve this page on GitHub