Incident report 16 October 2026

Two incidents.
One day.

SteamWatch briefly stopped watching Steam twice: first because runtime state piled up, then because its tools documented every detail of the repair.

Resolved statistics are once again larger than their paperwork

What happened

Two different logs. One lesson: temporary state needs an exit.

Incident 01 Worker state

25 GB of temporary enthusiasm.

Repeated worker restarts left disposable runtime state and diagnostics behind inside the app container. The application kept working until there was no room left to work in.

25 GB
runtime state and logs
~27 GB
space reclaimed

Incident 02 Inspector log

The debugger became the dataset.

A local development inspector recorded the database traffic used to collect game statistics. Every request made more evidence about the request, until the runtime ran out of memory describing its own work.

53,751,071
lines written
1.36 GB
one diagnostic log
~1.4 GB
runtime heap reached

The feedback loop

A tiny operational tragedy in four steps.

Nothing was wrong with the Steam data itself. The collector, database, and public records remained intact. The problem was an overachieving observer sat next to them.

  1. 01The collector asks for game statistics.
  2. 02The inspector records the request and response.
  3. 03The log grows with every collected sample.
  4. 04The runtime reads too much log data and falls over.

The fix

We told the tools to stop taking notes.

01

State cleanup

Disposable Miniflare state is cleared on worker start, and old Wrangler logs have a hard retention limit.

restart cleanup enabled
02

Inspector off

The production worker now explicitly starts without the local development inspector.

dev.inspector = false
03

Disk logs off

Wrangler's disposable diagnostic logs are disabled in the production container.

WRANGLER_WRITE_LOGS=false

Statistics resumed. The irony was retained.