Scheduling

A Pro feature. Sweeps run daily, weekly or monthly, and somebody gets told what happened.

Setting the schedule

Nuke → Settings → Schedule. Pick a frequency and an hour; weekly takes a day of the week, monthly a day of the month. The screen tells you when the next one is due.

Day of month is capped at 28 on purpose. “The 31st” silently skips February and three other months a year, which is a bug report waiting to happen.

How “due” is decided

Nuke thinks in occurrences, not intervals. A sweep is due when the most recent scheduled moment is newer than the last run — not when “24 hours have passed”, which drifts a few minutes later every day and eventually lands a 3am job in the middle of the afternoon.

“When did it last run?” is answered from the run ledger rather than a stored timestamp, so there is one source of truth and no way for the two to disagree after a database restore. A schedule that has never run is due immediately, rather than waiting for its second occurrence.

Two ways to fire it

Cron (recommended)

Ask Nuke every so often whether a sweep is owed:

*/15 * * * * cd /path/to/site && php craft nuke/sweep/due --dry-run=0

nuke/sweep/due exits 0 whether or not anything was owed — “not due” is not an error, and a cron job that reported failure four times an hour would be switched off within a week.

--dry-run=0 is required. Like every other console command, this one previews by default. A dry run leaves no ledger row, so it does not count as the scheduled sweep having happened and the next real run is still owed — but if your crontab is missing the flag, nothing will ever actually be cleaned.

If your cron can express the schedule itself, skip the middleman and run the sweep directly:

0 3 * * 0 cd /path/to/site && php craft nuke/sweep/run --dry-run=0

Control panel traffic

For sites without cron. Set How due sweeps start to Control panel traffic and Nuke checks, after each control panel page request, whether a sweep is owed — and if so queues one. Nothing is ever deleted inside a page request; it only ever pushes a job.

Two simultaneous requests both finding a sweep due will queue exactly one job between them: the occurrence is claimed with an atomic cache write, and only the first caller wins.

The obvious caveat: this only fires when somebody logs in. It suits a site an editor uses daily and is unreliable for one nobody touches for weeks.

Emailed reports

Add recipients (environment variables like $NUKE_REPORT_EMAIL are fine), then choose when to send:

• After every run — including the ones that found nothing.
• Only when something was removed — the default, and the one that stays readable.
• Only when something went wrong — for a schedule you trust and want to hear about only on failure.

The sweep report lists only the tasks that did something. There is also a strike notification, on by default when notifications are on at all: a bulk deletion is precisely the event the rest of the team wants to hear about, and the person who performed it is often not the person who needs to know.

A mail server that is down never fails a run. The sweep succeeded, the ledger already says so, and the notification failure is logged.

What a scheduled sweep runs

Every task that is switched on in settings, in the standard order. There is no separate “scheduled” task list — if you want a smaller set on a schedule, switch the others off and run them by hand, or use nuke/sweep/run --only= from your own cron line.

Scheduled runs are marked as such in the ledger, so the run history can tell a scheduled sweep from one somebody pressed a button for.