Find Hub has no published refresh timer. Researchers observed a roughly 9-hour limit for one finder-tag pair, while other eligible finders can still add newer reports.
A stale Find Hub pin isn't automatically a dead tag. Google documents finder-side rate limits, owner-side throttling, and default aggregation; independent research measured the unpublished intervals.
- Google’s cited public pages don’t state a refresh interval or SLA, but they do document deliberate rate limits and throttling.
- The roughly 9-hour figure applies to one finder phone and one tag, not to the network as a whole.
- Default busy-places mode needs reports from multiple Android devices before the owner sees an aggregated location.
- PETS researchers observed 10- and 5-minute owner throttles after about an hour of continuous retrieval.
- Dated field tests changed from hours-long gaps to minute-level updates, but none creates a guaranteed interval.
Does Google Publish a Find Hub Refresh Time?
No cited Google page supplies a published refresh clock. Google’s 2024 security post confirms that the network limits how often a nearby Android device can report one tag and throttles owner requests. It frames those controls as protections against real-time following.
Google’s Find Hub privacy page describes two relevant modes. “With network in busy places only” waits for multiple Android detections and displays an aggregated location. “With network everywhere” can accept a report from one participating device.
A June 2024 Google response recommends the broader mode for lower-traffic areas. It didn’t state an update target.
Treat any “updates every N minutes” claim as unofficial unless Google publishes it.
Three Delays That Can Stack
TU Darmstadt researchers examined the closed-source path in the 2025 paper “Okay Google, Where’s My Tracker? Security, Privacy, and Performance Evaluation of Google’s Find My Device Network”. The numbers below are observations, not Google specifications.
1. One finder-tag pair: roughly 9 hours
The linked paper found that one finder phone and one tag produced only one location report roughly every 9 hours. Another eligible phone can still report the tag, subject to aggregation and owner-side throttling.
That is a pair-level limit, not a network-wide timer.
One finder may remain blocked by default busy-place aggregation. Two distinct finders can satisfy the observed two-device threshold on their first eligible reports. Later reports from each pair face their own limit.
2. Owner retrieval: 10 or 5 minutes
Throttling began disabled for a newly paired tracker. After about an hour of continuous retrieval, an “in all areas” report blocked another update for 10 minutes from the latest timestamp. A high-traffic report blocked updates for 5 minutes.
Those intervals describe Play Services 24.23.25 and Find My Device 3.1.148. They aren’t a changelog or promise for current server constants.
3. Default aggregation: more than one finder
The researchers found that high-traffic reports reached the owner only after at least two reports from two distinct devices were available. Their client-side evaluation also found at least four locations inside a 324–644 m radius and a 60-minute window. The timestamp was rounded to the last 10 minutes.
Screen state added another delay: at least 5 minutes with the finder screen off and 15 minutes in power-saving mode. These upload delays differ from the 9-hour finder-tag limit.
Our offline-finding settings guide explains the four owner-facing modes. This article stays on the report pipeline.
Why 9 Hours Isn’t a Schedule
Put one tag in a quiet location with one participating Android phone. In default busy-places mode, its report may not satisfy aggregation. The map can keep an older pin.
Add a second independent finder. Their first eligible reports can meet the observed threshold, but repeated passes by the same phones don’t create unlimited reports.
A busy route has a different shape. Many distinct eligible phones can contribute newer reports, while the owner-side throttle spaces what reaches the app. The architecture can therefore produce hours in one place and minutes in another.
Local contributor density remains unknown. Google’s install-base claim doesn’t prove that a particular driveway has multiple eligible finders. Our Find Hub troubleshooting guide covers the local checks.
What the 9-Hour Number Can’t Prove
The observation predicts neither the next pin nor local finder density. It isn’t a published SLA.
Keep mechanism and outcome separate. A test can show what happened on one route; it can’t reveal Google’s current server constants without supporting evidence.
What Did Dated Field Tests Find?
| Date | Route or setup | Reported result |
|---|---|---|
| August 2024 | Leeds, UK to Auburn, New York postal shipment | Google-network tags appeared “firmly rooted”; the reported gap approached 80 miles |
| Late November 2024, reported January 2025 | Controlled lost-in-Paris test | Google-network Chipolo went more than 8 hours without an update |
| March 2026 report | Paris through Romania to Barcelona shipment | Find Hub showed 1- to 4-minute ages when checked; longest delay around 7 minutes outside flight time |
The August 2024 postal test reported that on day 4, AirTag and SmartTag2 could be followed in motion while the Google tags appeared “firmly rooted” at an earlier location.
The next date needs special care. Rita El Khoury’s Paris test ran in late November 2024 but was published on January 18, 2025. It reported about 1 minute for AirTag and SmartTag2 versus more than 8 hours for Chipolo ONE Point.
A March 2026 report described a Paris-Romania-Barcelona shipment. It reported Find Hub ages of 1 to 4 minutes when checked, with a longest delay around 7 minutes outside flight time.
The 2026 shipment doesn’t establish why performance improved or turn 1 to 4 minutes into a new SLA.
Stale Network Pin vs Local Failure
The 9-hour foreign-finder limit doesn’t explain failed local detection or Play Sound beside the owner’s phone.
Chipolo’s firmware notice says some POP units stopped updating or playing sound even while nearby after falling out of sync. Firmware 5.10.0 addressed the issue; LOOP and CARD shipped with the fix.
Use a simple boundary. Away from the owner with few distinct finders, aggregation and rate limits can explain a stale map. Beside the owner with failed local controls, the foreign-finder mechanism can’t.
For the local path, follow the Find Hub reset guide only after checking the broader troubleshooting list. A reset won’t create finder density or remove a server throttle.
Bottom Line
Roughly 9 hours is a researcher-observed limit for one Android finder reporting one tag, not a global Find Hub schedule. Default aggregation, upload delay, and owner throttling can stack on top. Dated tests show both hours-long stalls and minute-level updates, so keep every result tied to its year, route, and source.
FAQ
Does Google promise how often Find Hub updates?
Google's cited public documentation doesn't state a refresh interval or SLA. It does document finder-side rate limits, owner-side throttling, and default aggregation. Those controls can delay a pin. They don't provide a countdown to the next one.
What does the 9-hour number mean?
PETS researchers observed roughly one report per tracker from one finder phone every 9 hours. It isn't a global network interval. Another eligible phone can report the same tag. Aggregation and owner throttling still affect what reaches the map.
Does everywhere mode remove the 9-hour limit?
No. Everywhere mode can remove the default need for multiple finder phones by allowing one participating device to contribute. It doesn't remove the observed finder-tag rate limit. It also doesn't remove owner-side throttling. The modes solve a different bottleneck.
Why did a 2026 report show minute-level updates?
That report covered a European transit route with many possible distinct finder phones. Different eligible phones can contribute newer reports even when each finder-tag pair is limited. The shipment doesn't prove why it outperformed the earlier Paris test. Its 1- to 4-minute readings aren't a service promise.
Is a stale Find Hub pin proof that my tag is broken?
No. A tag away from the owner may be waiting for eligible finder reports, aggregation, or a throttle. A tag beside the owner that also fails Play Sound points to a different local problem. Separate those cases before resetting hardware. The troubleshooting path depends on which link failed.
Can Find Hub provide live tracking?
These controls are designed to make real-time following harder. The map shows an allowed last report, not a second-by-second route. Even dense routes can be spaced by owner throttling. Use a cellular GPS service when live, remote tracking is the requirement.
