Casebook/Case 17
Drift & incidents

When a generated feature file caused a global outage

A production incident reconstructed as an ML dependency and failure-containment lesson.

Reported by the primary sourceFACT LAYER

What we can attribute directly

Cloudflare published a post-incident account for its 18 November 2025 outage.

The account attributes the event to an internal system change rather than a cyberattack.

Read Cloudflare — 18 November 2025 outage Primary source · last checked 26 Aug 2026
01 · Problem & constraints

The operating envelope

Global request volume, generated configuration/features, rapid propagation, shared dependencies, and recovery pressure.

Actors

Model teams, platform owners, operators, downstream product systems, and people affected by decisions.

Evidence

Versioned data, configs, traces, artifacts, deployments, and outcomes aligned on one timeline.

Failure cost

A widely distributed component fails at once, producing a broad service impact that initially resembles hostile traffic.

02 · Architecture reconstruction

Trace the system before naming the bug.

  1. 01

    Producers emit versioned data or model artifacts.

  2. 02

    A platform validates, computes, stores, schedules, or routes them.

  3. 03

    Training or inference consumes the exact declared version.

  4. 04

    Telemetry joins the decision to system, data, and model identity.

  5. 05

    Operators compare outcomes, stop conditions, and the last known-good path.

03 · Symptoms & investigation

Follow the evidence boundary by boundary.

Symptoms

A widely distributed component fails at once, producing a broad service impact that initially resembles hostile traffic.

Investigation

Correlate first failure time with configuration generation, artifact size/content, rollout wave, and service crash signatures.

DIAGNOSTIC EXERCISE

Design three gates between artifact generation and global consumption that would bound this failure.

Open investigation scaffold
  1. Write the earliest known-bad timestamp.
  2. Compare exact identities on either side of that boundary.
  3. Find the smallest affected slice and a known-good counterexample.
  4. Separate mitigation from root-cause confirmation.
04 · Root cause & fix

Repair the contract, not only the symptom.

ROOT CAUSE

An invalid or unexpectedly large generated artifact crossed a trust boundary without sufficient validation and blast-radius control.

FIX

Validate generated artifacts, enforce size/schema limits, stage distribution, and retain a known-good snapshot.

Rollout

Restore known-good state first; re-enable generation behind progressive rollout and stop conditions.

05 · Rejected alternatives

Reason about the tempting shortcuts.

  • Continuing propagation while debugging downstream symptoms.
  • Treating internally generated artifacts as inherently trusted.
06 · Monitoring after the fix

Make recurrence visible early.

01

Artifact size/schema invariants

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

02

Crash and reload rate

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

03

Distribution wave health

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

REUSABLE PRODUCTION PATTERN

Generated data can behave like executable configuration and needs release engineering.

Carry this pattern into assignments as a design constraint and into incident reviews as a hypothesis—not as proof about an unpublished system.