How long should a signed document URL remain valid?

Determine whether the link is issued when a user clicks Open, when a job enters a queue, or immediately before a worker fetches the source. A link created too early can spend most of its life waiting. Also verify the storage provider's exact expiry behavior, including whether validation occurs at request start and what happens when an interrupted download is retried. Do not assume that every storage system interprets expiry or resumable requests identically. Record clock synchronization requirements for the services that issue and validate credentials.

Collect queue wait, connection setup, source transfer, and retry delays under representative load. Use the agreed upper operating range rather than treating a single successful measurement as a guarantee. Separate source retrieval from conversion time when conversion no longer needs the link after downloading. If the worker must fetch again later, account for that explicitly. The resulting policy should explain which delays are covered, which failures request a fresh link, and which conditions terminate the job with a clear recoverable error.

A useful planning expression is issue-to-fetch delay + connection allowance + supported retry window. This is a way to reason about the budget, not a universal expiry formula. Check whether the storage provider evaluates expiry at request start, permits an ongoing transfer to finish, and requires renewed authorization for range requests or retries. Those semantics determine which parts of a long transfer consume the usable window.

There are two common choices. Issuing at job submission is simpler when the integration only accepts a ready URL, but the link spends time in the queue. Issuing immediately before retrieval reduces that waste, but requires an authorized worker-side lookup or refresh mechanism. The latter must not become an unauthenticated endpoint that generates new links for arbitrary document IDs.

Measure the queue's slow periods, not just its empty state. Then test the expiry boundary deliberately with a disposable object. Record which component requests fresh access, whether it repeats the current permission check, and what the user sees if access has been revoked since the original job was submitted.