Most software updates look like nothing happened. The pages still load, nobody calls, and whoever pushed the change moves on. What that view leaves out is everything happening behind the page: an invoice being generated, a confirmation email waiting its turn in line, a nightly inventory sync sitting halfway through six thousand records.

Those are queued jobs. During an update, they are the part of your system most likely to fail in a way you hear about from a customer rather than from your monitoring.

The Laravel team shipped a small feature on August 11 that exists specifically because of this problem. It's worth understanding, not because you'll ever type the command yourself, but because it names a risk most business owners have never been told about.

The window nobody watches

A queue worker is a program that never stops. Unlike a web page, which loads your code fresh on every request, a worker boots your application once and keeps it in memory, pulling jobs off a list and running them one after another for hours or days at a time. That's what makes it fast. It's also what makes deploys interesting, because the worker is still running the previous version of your software until something deliberately restarts it.

So for a stretch of every release, two versions of your business logic are live at once. New visitors hit the updated site. Meanwhile a worker that started yesterday is still processing jobs using last week's rules: the old tax calculation, the old email template, the old definition of what "completed" means on an order.

The jobs themselves are frozen in time too. When something gets queued, it isn't executed on the spot. It's written down and picked up later, carrying a snapshot of whatever the code looked like when it was created. Change the shape of that job in your update, and a worker on the other side of the deploy has to make sense of a message written in a slightly older dialect. Sometimes it crashes, which is the good outcome, because at least you find out. Sometimes it runs and quietly produces the wrong result, which is the outcome that reaches a customer.

This is the class of bug that produces the sentence every developer dreads hearing: the update went fine, but the receipt still went out with the old total on it.

Taking the whole site down was the old answer

For years the standard fix was maintenance mode: put the entire application behind a placeholder page, do the work, bring it back. It's effective, and it's enormously blunt. You wanted the background workers to stop reserving jobs for ninety seconds. What you got instead was every customer on your site hitting an error page, including the ones just reading your hours or filling out a contact form. For a store, that's abandoned carts. For a service business, it's the one prospect who Googled you at exactly the wrong moment.

The alternative was to stop the workers by hand and remember to start them again, which is fine right up until the day somebody forgets. Jobs pile up silently. Nobody notices until the backlog is a day deep and a customer asks where their confirmation went.

Laravel added the ability to pause an individual queue in late 2025, which helped, but it created a bookkeeping problem of its own. Real applications don't have one queue. They have a handful with names like emails, reports, and imports, spread across more than one connection, and that list grows every time somebody ships a feature. A deploy script that pauses queues by name is a list that silently goes stale, and the queue it forgets is the one that breaks.

What changed this week

Laravel 13.25 added a single global switch. One command pauses every queue on every connection, and one resumes them, as the Laravel team documented in the release. No list to maintain, nothing to keep in sync with your feature work.

The detail worth noticing is what happens on the way back up. Resuming everything clears the global pause but deliberately leaves alone any queue that somebody paused on purpose. If your team parked the reports queue on Tuesday because a vendor's API was down, a deploy on Wednesday won't quietly restart it. That's a small decision by the contributor who built it, and it reflects the thing that actually matters here: the failure modes of deployment are known, documented, and designed around by people who have been burned by them.

Meanwhile, the jobs don't go anywhere. They sit in the queue, unprocessed, until work resumes. Nothing is lost. The site stays up the entire time. That's the whole point, and it's the difference between a release your customers never notice and one they email you about.

None of this is exotic. If your software runs background jobs of any kind, you already have this exposure, whether or not anyone has described it to you.

What to ask before your next update

You don't need to audit anyone's deploy script. You need one question, asked before the release rather than after: what happens to work that's already in progress when you push this?

A good answer is specific. It sounds like "workers get paused, we deploy, we restart them, and anything queued mid-flight picks up on the new code." It might mention that certain jobs get held back deliberately. The person answering has clearly thought about the overlap window because they've been bitten by it.

A worrying answer is abstract. "It's automatic" or "that's handled" or "we've never had a problem" are not descriptions of a process. The last one is especially worth pressing on, because this category of bug is quiet by design. Not having noticed it is not the same as it not having happened.

The follow-up question is about detection. If a job fails during a deploy, does anyone find out, and how fast? A failed job that lands in a table nobody looks at is functionally identical to a job that vanished.

This is the unglamorous half of running software, and it's most of what separates an application that gets more reliable over time from one that quietly accumulates weirdness. It's the reason ongoing maintenance is really about the machinery around your code rather than the code itself, why what happens after launch matters more than most people expect when they're still picking a developer, and why a maintenance plan that only covers plugin updates isn't covering the part that hurts.

If your software does real work in the background and you're not sure what happens to it during a release, that's worth a conversation. It's a short one, and the answer tends to be either reassuring or genuinely useful to know.