Rails 8.2 Callbacks and Background Jobs in Production

Callbacks feel harmless — until production traffic proves otherwise.

Rails 8.2 tightens execution order. Ruby 4.0 removes timing slack. Together, they turn poorly-placed callbacks into latency spikes and job backlogs.

Let’s talk about where callbacks break, and what to do instead.

Callbacks Hide Control Flow

This looks innocent:

after_commit :sync_crm

In Rails 8.2, this runs more predictably — and more frequently — than before.

The problem isn’t correctness. It’s invisibility.

If you can’t see when code runs, you can’t reason about performance.

Ruby 4.0 Exposes Timing Assumptions

Ruby 4.0 schedules work more honestly. That means callbacks that used to “feel async” now block visibly.

Background jobs pile up. Requests wait longer. Nothing crashes — it just slows.

Replace Callbacks with Explicit Boundaries

Instead of this:

after_commit :enqueue_job

Do this:

User.transaction do
  user.save!
end

UserSyncJob.perform_async(user.id)

Explicit beats clever every time.

Final Thoughts

Rails 8.2 didn’t break your callbacks. Ruby 4.0 didn’t either.

They just stopped hiding the cost. Having trouble with rails? Check out Ruby 3.5 Preview: What Matters for Rails in Production.