## TL;DR
The agent re-scans because a timeout leaves no record, so the target looks fresh every time. Give each target a failure budget of two timeouts, then quarantine it for the rest of the run and spend the time on unscanned targets instead.

```text
(agent re-scans TARGET after each timeout; same timeout repeats)
```

## Use this when
- The agent log shows the same authorized target timing out across multiple scan types, each followed by another attempt.
- The run is spending more time on one flaky host than on the rest of the scope.

## Not for this skill when
- Timeouts are spread across many targets. That is a network or rate problem, not a per-target loop.
- The target just needs a longer timeout once. A single adjustment is tuning, not quarantine.

## Steps
1. Count the timeouts per target in the run log. Verify: one target accounts for a disproportionate share of attempts.
2. Quarantine it: mark the target skipped-for-now with the timeout evidence attached. Verify: the planner's next-target selection excludes it.
3. Continue the run across the remaining scope. Verify: overall progress resumes instead of stalling on the flaky host.
4. At the end of the run, make one deliberate retry of quarantined targets with a longer timeout and a narrower scan. Verify: the retry is a single planned attempt, not the loop restarting.
5. Report quarantined targets as "unscannable within time budget" with the timeout logs attached. Verify: the report is honest about the gap instead of silent.

## Variant phrasings
### agent keeps retrying timed out target
The budget-burning phrasing.
### flaky target stalls agent scan run
The symptom phrasing.
### agent timeout retry storm one host
The rate-shaped phrasing.

Compatibility: harness scheduling fix; tool-agnostic.

## Why it happens
Timeouts are the least informative failure: no output, no error, just silence. Planners that treat "no result" as "not attempted" will keep attempting, and a host that times out once usually times out the same way ten times.

## Edge cases / pitfalls
- Quarantine is per-run, not permanent. A target that was down during the scan window may be up for the retest; the next run starts fresh.
- Do not quarantine a target the engagement specifically prioritizes without telling the test lead. Priority targets get manual attention, not silent skipping.
- If most targets time out, the problem is the tester box or the network path. Quarantining everything is a signal to stop and diagnose.
- The end-of-run retry should use a longer timeout than the attempts that failed; retrying with the same timeout just re-proves the timeout.

## Provenance

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