# Does a crash-loop threshold separate a crash loop from a slow first start? (brief: "check against every
# app's first-start restarts in the drill evidence"). Read 2026-09-24 12:50 CEST over documentation/audits/.
$ grep -rhoE '"restarts": *[0-9]+|RestartCount[=: ]+[0-9]+' documentation/audits | sort | uniq -c
   1831 "restarts": 0            <- harness state samples (172 files: bench to-/abort-states, memory samples)
     11 RestartCount=0
      1 RestartCount=9           SPIKE-app-update-2026-09-01.md:225 — a deliberately broken image (alpine:3.20), 37 s after start
      1 RestartCount=6           evidence-chaos-night-2026-09-17/round-1-notes.txt:18 — nextcloud, corrupt image layer (ExitCode 127): BROKEN
      1 RestartCount=12          evidence-chaos-night-2026-09-17/phase0-recovery.txt:213 — immich microservices, DB connection dropped at first-start import on a 6 GB guest; left broken that night
      1 RestartCount 9           evidence-drill-0243-2026-09-16/phase2-m1-oom.txt:23 — paperless at a 128M cap: OOM loop
Also measured tonight: 40 containers on both demo boxes + 9202 — no healthy container above 1 restart (A3/02).

VERDICT: no sample shows a HEALTHY app restarting during a first start. Every count >= 6 is a broken app
(crash image, corrupt layer, OOM cap) — the thing decision 28 stops. The one borderline case is immich's
first-start import (12 restarts): it did not recover that night, so stopping it would have been correct,
but it is the shape a slow-but-recovering first start would take. Row filed (immich first-start watch).
Docker's back-off matters more than the count: a FRESH container restarts fast (9 in 32 s, A3/30), a
long-running loop slows to ~1/min (A3/04) — so 10 in 10 min misses a steady loop; 6 catches both.
