Turbo Drive request timeouts: no built-in limit for hung visits and form submissions

Short answer

There is no documented, built-in network timeout for Turbo Drive visits, frame navigations, or form submissions in Turbo 8.x. An in-flight fetch ends only when the server responds, the browser's network layer fails, or Turbo aborts it because a newer navigation superseded it. The intended approach is exactly what you suspected: attach an AbortSignal to event.detail.fetchOptions inside a turbo:before-fetch-request listener.

Why the UI gets stuck

Turbo's progress bar and the disabled form submitter are tied to the lifecycle of the fetch request, not to any timer. If the fetch promise never settles, neither does the activity state. Aborting the fetch rejects the promise with an AbortError, which Turbo treats as request failure: the activity state ends, the progress bar hides, and — for forms — the submitter is re-enabled when the submission settles. Submitter re-enabling on error has been refined across 8.x patch releases, so verify this against your installed version rather than assuming it.

Implementation

const TIMEOUT_MS = 15_000

document.addEventListener("turbo:before-fetch-request", (event) => {
  const fetchOptions = event.detail.fetchOptions
  // Do not clobber an existing signal; only set one if Turbo hasn't.
  if (!fetchOptions.signal) {
    fetchOptions.signal = AbortSignal.timeout(TIMEOUT_MS)
  }
})

document.addEventListener("turbo:fetch-request-error", (event) => {
  // Present your retry UI here instead of failing silently.
})

AbortSignal.timeout(ms) requires a reasonably modern browser. For older targets, use an AbortController plus setTimeout, and clear the timer when the request completes.

Interaction with Turbo's own cancellation

Turbo's automatic cancellation on rapid navigation uses its own internal AbortController. The one real edge case is the one you flagged: blindly overwriting fetchOptions.signal can detach Turbo's cancellation path. Guard with an existence check (as above) or compose the signals — for example, abort your controller from Turbo's signal via signal.addEventListener("abort", ...). With that handled, the two mechanisms coexist: whichever fires first settles the request, and Turbo's bookkeeping proceeds normally either way.

Coverage of frames and forms

Turbo Frames and form submissions run through the same fetch pipeline, so one listener covers all three contexts. You can branch on event.target (e.g., a turbo-frame element or a form) to apply different timeouts per context — a shorter bound for frame refreshes, a longer one for form posts.

Caveats

• Client-side abort does not stop server processing. Your idempotency handling remains necessary, and very short timeouts raise the risk of a user retrying while the original request is still executing server-side — effectively a double submission.
• An aborted visit can surface as console noise or an unhandled error if you don't listen for turbo:fetch-request-error. Wire that listener to your retry UI.

Verification

1. Confirm your exact @hotwired/turbo version (package.json or importmap) and inspect its bundled FetchRequest source or type definitions for how the signal is consumed.
2. Point a test endpoint at a delayed response (or throttle in dev tools), fire a visit and a form submission, and confirm the progress bar hides and the submitter re-enables when the timeout fires.
3. Navigate again mid-hang to confirm Turbo's own abort still works alongside your signal.
4. Check server logs to confirm the aborted request still completed, proving your idempotency path is actually exercised.

One open detail that would change the recommendation: if any of your hung endpoints are GET visits you expect to be cache-restorable, a timeout abort bypasses Turbo's snapshot cache for that navigation — mention if that applies, since it may argue for a longer bound on visits than on submissions.