A finished response does not make a durable job
Next.js after moves incidental work beyond the response. Important jobs still need persistent intent, bounded retries and evidence that the work completed.
By 
Paul. Languages and frameworks
A customer seeing an order confirmation and a warehouse receiving the order are different events. Moving the warehouse request beyond the HTTP response can shorten the customer's wait. It also creates a gap in which the application has promised something that another system has not completed. Important work needs a recorded obligation and a recovery path across that gap.
Looking back from November 2026 at the week beginning 11 December 2024, Next.js supplied a useful example. Its 15.1 announcement, dated 10 December, made after stable for work performed after the response finishes streaming. The release predates this research week by one day. Its significance here concerns execution lifetime, rather than the framework's separate caching decisions.
Decide what the response promises
Consider an illustrative shop that records an order and then requests fulfilment. This is a design example, not an AL+ deployment or a measured experiment. If the page says the order was accepted, the system needs a way to find that obligation even if the request process disappears. A callback held only by that process cannot provide the record after the process has gone.
The first decision is therefore the meaning of acceptance. An accepted order may legitimately remain pending fulfilment. It should not silently vanish from the work list because a process restarted. Store a state that distinguishes accepted, dispatched and completed work, with a stable identifier connecting the transitions. A customer-facing status can then describe the actual business state instead of treating a successful response as proof of everything that follows.
This distinction changes incident handling. Without a persistent record, support may have to infer missing work from complaints. With one, an operator can find accepted orders that have not progressed and decide how to recover them. Persistence does not guarantee fulfilment; it makes the outstanding obligation visible after the original request is unavailable.
Extending lifetime has a boundary
The current after reference, consulted in November 2026, describes execution within the route's default or configured maximum duration. This is later operational documentation, not a frozen December 2024 contract. The dated release also described support for platform-provided waitUntil primitives. Neither description establishes a durable queue with automatic recovery after process loss.
That matters when separating two failures. A callback may throw while the process is still running, leaving an observable error. A process may instead exit before the work finishes, leaving no opportunity for that callback to report its own failure. Handling an exception addresses the first case. It does not reconstruct the work after the second case.
A timeout introduces another uncertainty: the downstream system may have completed the request even though the caller did not receive confirmation. Repeating the call can then duplicate the effect. A retry policy needs an answer to that ambiguity, such as a stable operation identifier that the receiving system recognizes, or reconciliation before another attempt. Merely scheduling the same callback again is an incomplete design.
Record the obligation before acknowledging it
For consequential work, a useful proposal is to save the order and its pending fulfilment intent together, then let a worker claim the pending work. An outbox is one way to arrange that relationship. The specific storage and transport can vary. The important property is that acknowledging acceptance does not depend on an unrecorded future enqueue operation succeeding.
The worker still needs a completion contract. Define which downstream response counts as acceptance and which business evidence counts as completion. A transport acknowledgement might mean only that a message arrived. It may not mean the warehouse allocated stock or dispatched a parcel. Keep these meanings separate when choosing the status shown to customers.
Bound retries and give unresolved work an owner. A permanently invalid address is unlikely to improve through repeated transmission. An unavailable service may recover. Both conditions deserve visible states, with enough context for an operator to act without replaying unrelated work. These are architecture recommendations; this article supplies no failure-rate estimate or claim that a particular queue implementation meets them.
Best-effort analytics is a reasonable exception
A queue can be excessive for an optional page-view event. If occasional loss is acceptable, a post-response callback may offer a simpler way to avoid adding analytics latency to a page. The team can explicitly accept incomplete counts and keep the main interaction independent of the analytics destination.
The exception depends on what the event is used for. An optional diagnostic breadcrumb and an audit record establishing who approved a refund carry different obligations. Calling both logging obscures the difference. If missing events would invalidate billing or prevent a required investigation, review the storage and recovery contract rather than inheriting the best-effort decision from a convenient function name.
Complexity has a cost in the other direction too. Persistent workers need operation, inspection and recovery procedures. A team should not introduce them solely because all background work sounds important. Choose the mechanism from the consequence of losing or repeating the work, and document where loss is intentionally tolerated.
For custom software, write one sentence before choosing the callback or worker: what remains owed after the customer receives this response? If the answer survives a process restart, the record of that obligation should survive too. Then define how someone can tell that it was completed, and who handles the cases that never reach that state.