cloudparts

Chaos MonkeyDormant

Netflix’s original chaos tool: on weekdays it picks instances at random from each app managed by Spinnaker and terminates them, so teams build services that survive losing a machine.

What it is
Chaos engineering
Type
Open source
Made by
Netflix
License
Apache 2.0
Status
Dormant. No code changes since October 2024 (last release v2.1.3, January 2025), though Netflix’s lifecycle file still marks it active.
Facts checked
24 October 2026
Website Source code

What it is

Chaos Monkey does one thing: it terminates virtual machine instances and containers in production at random. It isn’t a service but a Go binary run by cron. Once each weekday a schedule job decides which instances will die that day and writes the terminations into a cron file; a terminate job then kills each one at its time, starting at a configured hour in a configured time zone so that engineers are at work when it happens.

Version 2 is built on Spinnaker, Netflix’s continuous delivery platform, and only works for apps deployed with it. Spinnaker supplies the list of instances, and each app turns Chaos Monkey on in Spinnaker’s config tab. There the owner sets the mean time between terminations (default two days) and the minimum time between them (default one day), and whether a group is the whole app, a stack or a cluster. Accounts, regions or stacks can be excluded. Chaos Monkey keeps its schedule and termination history in MySQL. It can also be told to stand down during outages, but only through an outage checker you write yourself in Go against its Outage interface.

Why teams pick it

  • Simple and blunt: random instance loss on a schedule is the most common failure in a cloud, and it forces every service to cope with it
  • Runs only in working hours on weekdays, with per-app frequency and opt-outs, so teams can start gently
  • Works on any cloud Spinnaker deploys to, and has been tested with AWS, Google Compute Engine and Kubernetes

Watch out for

  • Requires Spinnaker and a MySQL database; without Spinnaker it can’t find or terminate anything
  • Only kills instances: no latency, network, resource or dependency faults, which Netflix split off from version 2.0
  • Little maintenance: the last code change was in October 2024, with open issues asking whether the project is retired
  • No steady-state check of its own: it terminates on schedule whether or not the service is healthy, unless you write and compile in an outage checker

Alternatives

What all chaos engineering have in common →Compare side by side →
ToxiproxyOpen sourceA small TCP proxy from Shopify that sits between your app and a dependency such as MySQL or Redis in tests, and adds latency, timeouts, cut connections or bandwidth limits on command through an HTTP API.

How it fits with other technologies

Set up the database, then generate each weekday’s schedule from cron · bash

# once: create the database, then the schema (credentials in chaosmonkey.toml)
mysql -e 'CREATE DATABASE chaosmonkey;'
chaosmonkey migrate

# /etc/cron.d/chaosmonkey-schedule: at 12:00 UTC, Monday to Friday,
# pick today's victims and write them to /etc/cron.d/chaosmonkey-daily-terminations
0 12 * * 1-5 root /apps/chaosmonkey/chaosmonkey-schedule.sh

See it in a real stack

No architecture uses Chaos Monkey yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2010–2024

When Netflix moved its streaming service to AWS, it designed every system to keep working when the systems it depended on failed. In a December 2010 post on lessons from the move, John Ciancutti wrote that “the best way to avoid failure is to fail constantly”, and that one of the first systems Netflix engineers built on AWS was the Chaos Monkey, whose job was “to randomly kill instances and services within our architecture”.

In July 2011 Netflix described a Simian Army that grew from it: Latency Monkey, Conformity Monkey, Doctor Monkey, Janitor Monkey, Security Monkey, 10-18 Monkey and Chaos Gorilla, which simulated losing a whole Availability Zone. Chaos Monkey was open-sourced on July 30, 2012, as part of the Simian Army; it found AWS Auto Scaling Groups and killed one instance per group, by default on non-holiday weekdays between 9 a.m. and 3 p.m., and in the previous year it had terminated over 65,000 instances.

In October 2016 Netflix released Chaos Monkey 2.0, now written in Go, run as a cron job and driven through Spinnaker, so it could reach AWS, Google Cloud, Azure and Cloud Foundry. It dropped the SSH-based faults, such as burning CPU or disabling a disk, which Netflix considered too “insidious” to inject at random. The older Simian Army repository was later archived. The project has had few changes since; its last commits, in October 2024, updated it for MySQL 8.0.

Why it’s built this way

Random terminations in production
Netflix wanted to find out that an app couldn’t survive losing an instance when people were around to fix it, not when paged at 3 a.m., and wanted to keep checking as code changed week to week.
Business hours only
Most apps were built to survive an instance going away, but for those that weren’t, Netflix wanted engineers alert and able to respond, so the schedule ran only on weekdays during the working day.
Opt-out by default at Netflix
If an app owner did nothing, Chaos Monkey acted on the app, which made resilience the default. The open-source version also offered opt-in, for organisations testing the water.
Built on Spinnaker in 2.0
Using Spinnaker’s view of deployments let one tool reach every cloud Spinnaker supports, instead of Chaos Monkey talking to AWS Auto Scaling Groups directly.

Timeline

  1. 2010

    Netflix describes Chaos Monkey as one of the first systems it built on AWS

  2. 2011

    The Simian Army is announced

  3. 2012

    Open-sourced on July 30, as part of the Simian Army

  4. 2016

    Chaos Monkey 2.0: written in Go, run through Spinnaker

  5. 2024

    Last code changes, updating it for MySQL 8.0

Sources9 · facts checked 24 October 2026

Improve this page on GitHub