Not every slow thing deserves a queue. Warming a cache entry, writing an analytics row, pinging a webhook you do not care much about: all worth getting off the response, none worth a jobs table row and a worker to consume it.

Laravel has a middle option:

WarmDashboardCache::dispatchAfterResponse($user);

The user gets their response immediately, and the work runs right afterwards. No queue is involved at any point.

What it actually does

It is simpler than it sounds. The call registers a terminating callback on the container, and when the framework finishes the request it runs that callback with dispatchSync:

$this->container->terminating(function () use ($command) {
    $this->dispatchSync($command);
});

So the job runs synchronously, in the same PHP process, after the response has been flushed to the browser. ShouldQueue on the class makes no difference here. Nothing is serialized, nothing is written to Redis or the database, and no worker ever sees it.

You can get the same behaviour on a normal dispatch chain:

WarmDashboardCache::dispatch($user)->afterResponse();

What you are giving up

This is the part to be clear-eyed about, because the API looks like queueing and behaves nothing like it.

  • No retries. It runs once. If it throws, that is the end of it.
  • No failed_jobs row. The exception is reported to your error handler, but there is no record to inspect or retry later.
  • No durability. If the process is killed mid-work, that work is simply gone. Nothing knows it was supposed to happen.
  • The process stays busy. The user is not waiting, but that PHP-FPM process is. It cannot serve another request until your work finishes, so a slow job here quietly reduces how much traffic the server can handle.

That last one is the trap. A queue moves work to a pool you scale separately. This moves work behind the response but keeps it on your web tier.

What it genuinely suits

Small, fast, and optional. Under a second, and nothing breaks if it silently does not happen:

  • Warming a cache entry the next page will want
  • Writing an analytics or audit row
  • Bumping a counter or clearing a related cache key
  • Firing a notification you would not chase if it went missing

If you find yourself wondering whether it retried, you have picked the wrong tool.

What it does not suit

Anything with a real-world consequence. Payments, emails a customer is expecting, provisioning, anything touching a third party that can be slow or down. Those need durability and retries, which means a real queue and the failure handling that goes with it.

Also avoid it for anything slow. Ten seconds of work after the response is ten seconds that process is unavailable, and on a busy site that is how you run out of PHP workers while the CPU sits idle.

In the console it is not "after the response"

There is no response in a command or a queue worker. The terminating callbacks run when that process finishes its work instead, which for a long-running worker may be much later than you expect. Treat dispatchAfterResponse as an HTTP-request tool and use a normal dispatch elsewhere.

Wrapping up

dispatchAfterResponse() runs a job synchronously in the same process once the response is out, using a terminating callback rather than the queue. It buys you a fast response with no infrastructure, and it costs you retries, durability, and a bit of web-tier capacity while it runs. Use it for small optional work, and reach for a real queue for anything you would be upset to lose.

Related