The UPDATE without a WHERE has a row count in the history

Support says every customer's plan reads free since about two. Nobody deployed anything.

GET /api/v1/sqlite/history?db=app.db lists every statement that ran through the sqlite URL, newest first: query text, timestamp, duration_ms, rows_affected, status. You don't read the SQL. You sort by rows_affected. One line stands out: UPDATE accounts SET plan = 'free' at 14:02:11, rows_affected: 8412. Everything above it touched one row. The support tool's bulk-edit form had lost its WHERE clause.

Now you have the minute, the statement, and the blast radius. The 14:00 snapshot puts the disk back; the two minutes of legitimate writes in between are the lines above it in the same list, ready to replay.

On a hosted database you'd be paying for a log tier and guessing at the minute. Here the database kept its own record.

The incident had a row count before it had a name.