A Chaos Gameday Plan Prompt That Sets the Blast Radius

Chaos engineering has a reputation problem: people hear "break things in production" and picture recklessness. Done right, it's the opposite. A gameday is a planned, bounded experiment with a hypothesis you can falsify and an abort button wired before anyone touches anything. The hard part isn't the tooling. It's writing a plan that's safe, specific, and falsifiable. A chaos engineering gameday prompt turns a service description into exactly that plan.

The prompt worth reusing returns five locked things: a hypothesis in "if X then Y within Z" form, the blast radius, abort conditions, the roles for the exercise, and a rollback procedure. Same structure every gameday, so safety isn't improvised.

What a chaos gameday prompt produces

A chaos engineering gameday prompt is a reusable AI prompt that converts a service description and its dependencies into a structured, bounded gameday plan. The locked output, hypothesis, blast radius, abort conditions, roles, rollback, is what makes the exercise repeatable and safe rather than a one-off adventure.

The how-to guides are good but manual. oneUptime's gameday guide ships YAML and Python snippets and a solid definition of a gameday as a planned failure-injection event, but it stops short of a prompt that converts your service into a plan. TechTarget's gameday setup tip walks the process in prose. Neither gives you a reusable, variable-driven plan with a locked output contract.

What you can do with this prompt

• Draft a complete gameday plan for a service from a one-paragraph description.
• Generate a falsifiable hypothesis with a time bound, not a vague "see what happens."
• Define the blast radius up front so the experiment can't escape its scope.
• Produce abort conditions and name who can pull the stop.
• Build the runbook the gameday is meant to validate, then test it.

Anatomy of the prompt pack

Variables
  {{service_description}} – what the service does and its role
  {{dependencies}}        – upstream/downstream, data stores, queues
  {{failure_to_inject}}   – e.g. DB read-only, dependency latency, pod kill
  {{environment}}         – staging or prod; scope changes with it
  {{abort_metric}}        – the signal that triggers an immediate stop

Prompt
  Role: SRE designing a safe, bounded gameday.
  Task: build a falsifiable plan with hard safety boundaries.
  Output contract (locked):
    1. Hypothesis     – "if {{failure_to_inject}}, then Y within Z"
    2. Blast radius   – in scope / explicitly out of scope
    3. Abort conditions – metric threshold + who can call abort
    4. Roles          – facilitator, operator, observer, comms
    5. Rollback       – exact steps to restore normal operation

The hypothesis format is non-negotiable. "If the database becomes read-only, the service switches to cache reads within five seconds with no user-facing errors" is testable. "Let's see how the service handles a database failure" is not. The time bound is what makes the result a pass or a fail instead of a discussion.

How models behave when planning a gameday

Claude holds the five-section contract well and is the most consistent at writing a falsifiable hypothesis with a real time bound rather than a soft one. GPT-4o proposes creative failure modes worth testing but tends to widen the blast radius unless you tell it to default to the narrowest scope. Gemini is strong at enumerating dependencies that should be marked out of scope but sometimes omits the "who can call abort" line, so restate that the abort owner is mandatory.

A model can't know whether your cache fallback actually works. That's the whole reason to run the gameday. The plan is a hypothesis, not a guarantee.

Prompt-craft patterns

Pattern 1 — hypothesis or nothing. Refuse the vague version.

State the hypothesis as "if {{failure_to_inject}}, then [expected
behavior] within [time bound]." If you can't bound it in time,
say the experiment isn't ready and explain what's missing.

Pattern 2 — narrowest blast radius by default. Make scope-creep an explicit choice.

Default the blast radius to the smallest scope that can test the
hypothesis. List everything explicitly out of scope. Widening scope
must be called out as a separate, riskier option.

Pattern 3 — abort is mandatory. No plan ships without a stop.

Every plan must include an abort metric from {{abort_metric}}, a
threshold, and a named role authorized to call the abort. If
{{abort_metric}} is missing, refuse and request it.

Here's the opinion: a gameday without a falsifiable hypothesis isn't chaos engineering, it's just an outage you scheduled. The discipline is in the "within Z." If you can't say what should happen and how fast, you're not testing a system, you're poking it. Run the experiment to confirm a behavior, not to find out whether one exists.

Variables you'll set

Getting started

1. Refresh the dependency map for the target service.
2. Pick one {{failure_to_inject}} and name the {{abort_metric}}.
3. Run the prompt on Claude and check the hypothesis has a time bound.
4. Have someone who knows the system confirm the blast radius.
5. Run the gameday with the named roles and the abort owner present.
6. Feed the result into the runbook so the validated recovery becomes documented.

A gameday tests the recovery steps your runbook claims work, which is why this pairs with the runbook authoring prompt, and the spikes you inject are the ones your capacity planning prompt is supposed to absorb. The two exercises validate each other.

In the catalog, the Incident Postmortem Agent Pack turns gameday findings into structured records, and the Agent Operations Runbook Generator writes the recovery steps the gameday validates.

Bound the blast radius, write a hypothesis you can fail, and wire the abort before you start. A gameday isn't recklessness. It's the safest way to learn what breaks.