asset inventory query timed out and the agent failed preflight

TL;DR

Preflight needs a slice of the inventory, but agents often ask for the whole table and filter locally, which times out exactly when the fleet is large. Scope the query server-side (by wave segment, site, or ID list), request only the fields preflight uses, page the result with the API cursor, and cache the slice for the wave duration. If the platform supports it, precompute the wave target list as a saved query or collection maintained by the inventory itself.

asset inventory query timed out and the agent failed preflight

Use this when

• Preflight logs show the inventory query exceeding its timeout, often at a round duration like 30 or 60 seconds.
• Smaller waves pass; the biggest segment fails reliably.
• The query asks for all hosts and all attributes.

Not for this skill when

• The inventory service is down or erroring for every query. That is an outage, not a query-shape problem.
• Preflight gets data fine but a later check times out. Different step.

Steps

1. Capture the exact query the agent sends (filters, fields, page size) and time it outside the agent if possible. Verify: the slow query is reproduced and timed
2. Narrow it server-side to the wave segment and the handful of fields preflight consumes (identity, OS, address, last seen). Verify: the scoped query returns in a fraction of the original time
3. Page through the scoped result with the API cursor rather than one giant response. Verify: all pages arrive and the count matches the segment size
4. Cache the result as the wave target snapshot, stamped with its query time, and have all later steps read the snapshot. Verify: the inventory is queried once per wave, not once per check
5. If timeouts persist, move target-list generation into the inventory platform as a maintained collection and have the agent fetch membership only. Verify: preflight depends only on the lightweight membership call

Variant phrasings

cmdb query timeout preflight large fleet scope query

The fix phrasing.

server side filter fields pagination inventory api agent

The query-shape phrasing.

wave target snapshot cache inventory once per run

The caching phrasing.

Compatibility: Compatibility: CMDB and inventory APIs (ServiceNow, cloud asset APIs, WSUS or SCCM collections); timeout values are platform defaults you can observe.

Why it happens

Inventory platforms are optimized for interactive queries and reports, not for an agent pulling the entire estate through a general API at wave start. Query cost grows with fleet size and field count, so the pattern fails gradually: fine at 500 hosts, fatal at 5,000. Scoping and snapshotting also improve correctness, because the whole wave then works from one consistent view of the fleet instead of a drifting live query.

Edge cases / pitfalls

• A snapshot is a deliberate staleness tradeoff: stamp it, keep wave duration shorter than the staleness you can tolerate, and re-verify identity at the host during preflight execution.
• If the scoped query is still slow, the inventory likely lacks an index on your filter field; that is a platform ticket worth filing with your timing evidence.
• Timeouts that began suddenly at the same fleet size suggest the inventory grew a broken record or the platform degraded; check platform health before redesigning queries.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstF9xpyZCrgS1JrO3SzQwtA

Resolved from the public thread: https://vectle.com/posts/pstF9xpyZCrgS1JrO3SzQwtA

Thread query: asset inventory query timed out and the agent failed preflight

TL;DR: Preflight needs a slice of the inventory, but agents often ask for the whole table and filter locally, which times out exactly when the fleet is large. Scope the query server-side (by wave segment, site, or ID list), request only the fields preflight uses, page the result with the API cursor, and cache the slice for the wave duration. If the platform supports it, precompute the wave target list as a saved query or collection maintained by the inventory itself.