alt-tabbing back fires 63 xhr requests on tanstack query v5, where do i look TanStack Query

For the 21 entries, stop reading the devtools list - it truncates nested objects, so filters:{...} will look identical for keys that are nothing alike. Dump the hashes instead:

queryClient.getQueryCache().getAll()
  .filter(q => q.queryKey[0] === 'todos')
  .forEach(q => console.log(q.queryHash))

Diff two of those strings and the culprit falls out immediately. Nine times out of ten it is a Date somewhere in the filter object being rebuilt on render, because it serialises down to the millisecond.

Two separate things are happening and you are treating them as one.

The burst: focus refetching only touches queries that are active and stale. Your staleTime is the default 0, so every active query is stale the instant it resolves, so all of them refetch. Six panels with three or four queries each, plus dependents that fire once their parent resolves, gets you to 60-odd without anything being wrong. Set a real staleTime and most of it evaporates:

defaultOptions: { queries: { staleTime: 30_000, gcTime: 5 * 60_000 } }

A dashboard where data one refresh old is unacceptable is a dashboard that wants a socket, not polling on focus.

The 21 entries: inactive ones (0 observers) are leftovers held for gcTime, and they do not refetch on focus. They are not sending requests. They are just evidence that something in your key changes more often than it should - which is worth chasing, but separately from the burst.

The other half of this is that six panels are mounted when only one is visible. A tab layout that renders all tabs and hides them with CSS keeps every query in those tabs active forever - subscribed, stale, and refetching on focus for content nobody is looking at. Unmount the hidden ones. Query keeps the data around for gcTime so switching back is instant anyway, and your focus burst drops by whatever fraction of the panels are offscreen.

The inline object in your key is the bug. ['todos', { status, page, filters }] builds a brand new object on every render, so the key is a new reference each time and Query treats it as a new entry. Wrap it in useMemo and the 21 entries collapse to one.

Minor, but check whether some of the 63 are OPTIONS preflights. If your dashboard is on a different origin from the API and you send a custom header, every request comes in pairs and your real request count is 32. Filter by method before you trust the number you are chasing.

refetchOnWindowFocus: false is the catch (e) {} of data fetching. It works, right up until the day you need to know why the page is showing yesterday.