Infrastructure & Operations › Working in Production

One-Off Scripts

Scripts run once against production, and why they deserve review and tests too.

Also known as: one-off script, throwaway script, migration script

A one-off script is a small program you run once against production: a backfill, a data correction, a cleanup, a migration. It feels disposable — you write it in an afternoon, run it, and move on. But it touches real data, and “disposable” is exactly why it’s dangerous: nobody reviews it, it’s never tested, and it has no second chance if it’s wrong.

Treat it like code that matters, because it is.

• Review it. Someone else reads it before it runs, especially the WHERE clauses.
• Test on a copy. Run it against a snapshot or a test database first, not against production.
• Back up first. If it changes or deletes data, have a backup to fall back on.
• Make it idempotent. If it dies halfway and you re-run it, it shouldn’t double-apply. Prefer updates that check current state over blind increments.
• Log what it did. Record the before/after or write to audit columns, so there’s a trail.
• Run it in small batches, inside transactions, so it doesn’t lock a table or hammer the database.

# reviewed, idempotent, bounded
for batch in fetch_users_missing_plan(limit=500):
    set_plan_if_missing(batch)   # no-op if already set

The classic mistakes: hand-typing the script directly into a production console (no review, no record), skipping the backup, and writing something that only works once — so a retry after a crash corrupts data. Keep the script itself somewhere version-controlled too, so future-you can see what changed what.

A one-off script is a small data fix or query; see ad-hoc queries for the read-only side. Run them under proper break-glass access, and capture the steps in the runbook so the next person doesn’t rewrite it from scratch.