Tumult Logo GameDay Is Here: From Individual Tests to Compliance Programmes

Tumult Banner

Part 14 of the Tumult series. ← Part 13: Load During Chaos

Running a single chaos experiment proves a single point of resilience. Your database recovers from a connection kill. Good. But an auditor asking about DORA Article 24 compliance doesn’t want to see one test — they want to see a testing programme: multiple scenarios, measured outcomes, recovery validation, and evidence that you do this regularly.

That’s what GameDay delivers.

What Is a GameDay?

A GameDay is a coordinated campaign of experiments:

GameDay: Q2 PostgreSQL Resilience Programme
  ├── Experiment 1: Connection kill under load
  ├── Experiment 2: Container pause (5s total outage)
  ├── Experiment 3: CPU stress injection
  ├── Experiment 4: Memory stress injection
  └── Shared load: k6 running throughout

All experiments run in sequence under a shared load generator. They share a single OTel parent trace (resilience.gameday). Their results aggregate into a resilience score that maps directly to compliance articles.

Creating a GameDay 

tumult gameday create q2-postgres-resilience \
  --load k6 --load-script examples/k6/smoke-test.js \
  --experiments gamedays/pg-connection-kill.toon,gamedays/pg-container-pause.toon,gamedays/pg-cpu-stress.toon,gamedays/pg-mem-stress.toon \
  --framework dora

This scaffolds a .gameday.toon file:

title: Q2 PostgreSQL Resilience Programme

regulatory:
  frameworks[2]: DORA, NIS2
  requirements[3]:
    - id: DORA-Art24
      description: ICT resilience testing programme
      evidence: Quarterly GameDay with 4 fault scenarios under shared load
    - id: DORA-Art25
      description: Scenario-based testing of ICT tools and systems
    - id: DORA-Art11
      description: Response and recovery

load:
  tool: k6
  script: examples/k6/smoke-test.js
  vus: 5
  duration_s: 60.0

experiments[4]:
  - path: gamedays/pg-connection-kill.toon
    compliance_maps[1]: DORA-Art25
  - path: gamedays/pg-container-pause.toon
    compliance_maps[2]: DORA-Art25, DORA-Art11
  - path: gamedays/pg-cpu-stress.toon
    compliance_maps[1]: DORA-Art25
  - path: gamedays/pg-mem-stress.toon
    compliance_maps[1]: DORA-Art25

scoring:
  pass_threshold: 0.75
  mttr_target_s: 30.0
  recovery_required: true

Each experiment is mapped to specific compliance articles. The scoring config sets thresholds for what constitutes compliance.

Running the GameDay 

tumult gameday run q2-postgres-resilience.gameday.toon

The runner:

  1. Starts k6 as shared background load
  2. Runs each experiment in sequence
  3. Stops load, collects metrics
  4. Computes resilience score
  5. Writes a GameDay journal

The Resilience Score

The score is a weighted aggregate of four components:

Component Weight What it measures
Pass rate 30% Fraction of experiments that completed
Recovery compliance 25% MTTR within target, full recovery achieved
Load impact tolerance 25% Error rate during load (lower = better)
Compliance coverage 20% Mapped articles with passing experiments

Score interpretation:

  • 0.90+ → COMPLIANT
  • 0.75-0.89 → PARTIAL
  • < 0.75 → NON-COMPLIANT

This isn’t an arbitrary number. Each component maps to something an auditor can verify:

  • “Did your tests pass?” → pass rate
  • “Did the system recover within your declared RTO?” → recovery compliance
  • “Did your users experience degradation?” → load impact tolerance
  • “Which regulatory articles have you tested?” → compliance coverage

Why This Matters for DORA

The Digital Operational Resilience Act (EU 2022/2554) entered into force on 17 January 2025. It requires financial entities to:

  • Article 24: Establish an ICT resilience testing programme
  • Article 25: Execute scenario-based tests including performance and end-to-end testing
  • Article 26: Carry out threat-led penetration testing (TLPT) for systemically important entities
  • Article 11: Test response and recovery procedures with measured recovery times

A GameDay maps directly to these requirements:

DORA Article GameDay Evidence
Art. 24 — Testing programme The GameDay itself — structured, repeatable, documented
Art. 25 — Scenario testing Each experiment is a fault scenario with measured outcome
Art. 11 — Response & recovery MTTR measured per experiment, aggregate recovery score

The journal is the audit artifact. The resilience score is the compliance metric. The OTel trace is the forensic evidence.

NIS2 Coverage

The same GameDay also covers NIS2 (EU 2022/2555):

NIS2 Article GameDay Evidence
Art. 21(2)(c) — Business continuity Recovery validated after each fault
Art. 21(2)(f) — Effectiveness assessment Baseline vs chaos comparison via load metrics

One GameDay, two regulations, documented in a single journal.

Real Results

The Q2 PostgreSQL Resilience Programme ran against live Docker infrastructure via the MCP HTTP/SSE transport — the same way an external agent or CI pipeline would run it:

GameDay: Q2 PostgreSQL Resilience Programme
Status: COMPLIANT
Duration: 29.2s
Resilience Score: 1.00

  #1 [PASS] PostgreSQL connection kill under load (2197ms)
  #2 [PASS] PostgreSQL container pause — total unavailability (7402ms)
  #3 [PASS] PostgreSQL CPU stress — resource pressure (9331ms)
  #4 [PASS] PostgreSQL memory stress — resource pressure (9305ms)

Score breakdown:
  Pass rate:    1.00
  Recovery:     1.00
  Load impact:  1.00
  Compliance:   1.00

Four fault scenarios. 29 seconds. Full compliance evidence. The analytics store accumulates all results across runs — 67 experiments, 244 activities queryable via SQL.

Pipeline

The demo exercises the full agent-to-compliance pipeline:

Agent (HTTP client)
    │ POST http://localhost:3100/mcp
    ▼
tumult-mcp (14 MCP tools, session management)
    │
    ▼
tumult-core (5-phase lifecycle, GameDay orchestrator)
    │
    ├── tumult-db-postgres plugin → docker exec → PostgreSQL
    ├── tumult-containers plugin → docker pause/unpause
    ├── tumult-stress plugin → stress-ng CPU/memory
    └── tumult-analytics → DuckDB → resilience score → compliance map

Try It

One command runs the entire demo — starts infrastructure, connects via MCP, runs the GameDay, analyzes results, shows compliance mapping:

./scripts/gameday-demo.sh

Or step by step:

# Install
curl -sSL https://raw.githubusercontent.com/mwigge/tumult/main/install.sh | sh

# Start targets
./start.sh infra

# Run GameDay
tumult gameday run gamedays/q2-postgres-resilience.gameday.toon

# Analyze
tumult gameday analyze gamedays/q2-postgres-resilience.gameday.toon

# SQL analytics
tumult analyze --all --query "SELECT title, status, duration_ms FROM experiments"

Or use the pre-built Docker images (no Rust needed):

docker pull ghcr.io/mwigge/tumult:latest
docker pull ghcr.io/mwigge/tumult-mcp:latest

The resilience score tells the story. The journal is the evidence. The compliance mapping is the bridge between engineering and regulation.

Try Tumult at tumult.rs

Next in the series: Part 15 — The Road Ahead →

Tumult is open source under the Apache-2.0 license.