Run history

Once a strike has run there is, by design, nothing left to inspect. So what was intended, what the preview said and what actually happened all have to be written down at the time.

The ledger

Nuke → History lists every run, filterable to strikes or sweeps. Each row records:

• The target, rendered as the same sentence the preview showed — not a set of IDs to decode later, and it survives the section itself being deleted.
• Who ran it: a user, the scheduler, or the console.
• The note, if one was written.
• How much was removed, how much failed, and how long it took.

A row is opened before the work starts and closed after. A run that crashes half-way therefore still leaves a record saying what it was doing — exactly the run somebody will need to reconstruct.

The run screen

Opening a run shows what happened, and for a strike the target it came from, field by field. Three things are worth looking at:

Against the preview

The record holds the blast radius the run was approved against as well as the outcome, and compares them. “Exactly what the preview said” is the usual answer. A difference is not automatically a bug — content changes between previewing and running, and a queued strike may have waited — but a difference nobody can see is a difference nobody investigates.

The backup

The path, and whether the file is still on disk. A run whose backup has since been swept away says so, which is a useful thing to discover before you need it rather than after.

Errors

Individual failures are recorded against the run, up to the first twenty. A strike over 50,000 elements against a broken foreign key would otherwise write 50,000 near-identical strings into a JSON column; after the first handful the count is what matters, and the log has all of them.

The log

storage/logs/nuke.log, at info by default and kept for 30 files. It records the target and size of every strike before it starts, the outcome afterwards, every individual failure, and every sweep.

It is the authoritative trail and the ledger is the convenient copy — because the log survives the database it was deleting from, and an uninstall, and a restore from a backup taken before the run.

Retention

The ledger keeps the most recent 100 runs by default, pruned after each run. Raise it in settings if you want a longer history; the rows are small.

Pruning is by ID rather than by date. Two runs finishing in the same second would be an ambiguous cut, and “which of these two happened first” is a question people genuinely ask of an audit record.

Reading it from Twig

The ledger is exposed read-only at craft.nuke — see the Twig API. Useful for a status dashboard; there is deliberately no way to run anything from a template.