agent failed mid-sync when wsus approval check hit rate limit

TL;DR

Approval checks feel cheap, so agents poll them per update per group, and the WSUS or SUP API throttles the aggregate. Batch the checks (query approvals once per group or per sync, cache the result for the sync duration), respect throttling responses with backoff, and move repeated polling to a change feed or a schedule aligned with how often approvals actually change.

agent failed mid-sync when wsus approval check hit rate limit

Use this when

• Sync logs show throttling or 429-style errors from the WSUS or SUP API during approval verification.
• The sync succeeds when run at quiet times and fails during business hours.
• Call counts scale with updates times groups, revealing per-item polling.

Not for this skill when

• The WSUS server is down or its service is stopped. That is availability, not rate.
• The agent credentials lost API rights. Auth errors are constant, not load-shaped.

Steps

1. Count the approval API calls in a failing sync from the agent log and identify the polling loop shape. Verify: calls per sync and the throttling threshold are both estimated from evidence
2. Refactor to batch: fetch the approval set for the target groups once, build an in-memory map, and answer checks from the map for the rest of the sync. Verify: call count drops to a small constant per group
3. Add throttle handling anyway: on a throttling response, back off with jitter and resume, checkpointing sync progress. Verify: a throttled test sync completes without manual restart
4. Cache approval data across syncs with a short TTL, invalidating on approval-change events where available. Verify: back-to-back syncs reuse the cache and log when they do
5. Report the API budget in the sync summary. Verify: future growth (more groups) triggers a visible warning before it triggers throttling

Variant phrasings

wsus approval check rate limit batch api calls agent

The fix phrasing.

sup api throttling sync fails business hours

The load-shape phrasing.

cache approval state sync duration patch agent

The caching phrasing.

Compatibility: Compatibility: WSUS API (IUpdateServer) and ConfigMgr SDK or WMI providers; throttling behavior is deployment-specific.

Why it happens

WSUS-class APIs were built for console use: a human approves updates in bursts and the server idles between. An agent verifying approvals item by item generates console-impossible call rates, and the server protects itself. The data also changes slowly (approvals are human decisions), so aggressive polling buys nothing; batching and caching match the access pattern to how the data actually moves.

Edge cases / pitfalls

• If the throttling is actually the WSUS server being undersized (WsusPool pressure), the batch fix helps but the server maintenance skills in this vertical are the deeper remedy.
• Do not parallelize the batched calls to win back speed; that recreates the burst the server throttled.
• Approval state is decision data; a stale-cache bug here approves or skips the wrong updates, so keep TTLs short and log cache age with each decision.

Provenance

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