Tired of Rails one-off scripts becoming a nightmare? I built something for that.

Abd El-latif — Mon, 17 Nov 2025 21:51:23 +0000

You know the drill. You need to run a script once to fix some data, update user preferences, or migrate something. You write a rake task, run it, and then... did it actually run? Did it work? If something breaks halfway through, how do you know where to restart?

I got tired of this cycle, so I built script_tracker - a Ruby gem that treats your one-off scripts like migrations (but better).

What it does:

Tracks which scripts have run (no more "did I run this already?")
Wraps everything in transactions (rollback on failure)
Built-in progress logging ("Processing 1,247 of 10,000 users...")
Batch processing helpers (because memory matters)
Timeout support (no more runaway scripts)
Simple rake commands to manage everything

Before:

# Some random rake task
# Did this run? Who knows!
rake data:fix_user_preferences

After:

# Clean, tracked, logged
rake scripts:create["fix user preferences"] 
rake scripts:run
rake scripts:status  # See what ran and when

The best part? If your script fails halfway through, you know exactly where, and you can handle retries properly.

Why I built this:
Data scripts have burned every Rails dev. When you run something in production, it fails silently, or worse, it runs twice and corrupts the data. I wanted the same confidence we have with migrations, but for one-off scripts.

Real talk: This started as internal tooling at my company. We had too many “wait, did that script run?” conversations. Now our data migrations are as reliable as our schema migrations.

The gem is open source and ready to use. Would love feedback from fellow Rails developers who’ve felt this pain.

Check it out: https://github.com/a-abdellatif98/script_tracker

What’s your biggest one-off script horror story? I bet this would have prevented it.

Forem: Abd El-latif

Tired of Rails one-off scripts becoming a nightmare? I built something for that.