## TL;DR
You asked for more concurrency than the build allows or the target tolerates. Lower `-t` to a sane value (10 is a safe start), raise `--timeout` for slow responses, stay under the engagement's rate caps, and scale back up gradually only if the target handles it.

```text
Maximum number of concurrent requests
```

## Use this when
- Gobuster errors about maximum concurrent requests.
- The target is reachable (hand checks pass).
- The engagement has rate limits you must respect.

## Not for this skill when
- Requests time out with low concurrency. That is a target or network problem.
- The target is down. Confirm with the client contact.
- You need maximum speed regardless of impact. You do not; respect the scope.

## Steps
1. Drop concurrency: `gobuster dir -u YOUR_TARGET_HOST -w wordlist -t 10`. Verify: the error disappears.
2. Raise the timeout: `--timeout 10s` so slow responses are not counted as failures. Verify: timeout errors shrink.
3. Check the rules of engagement for rate caps and confirm your effective rate is under them. Verify: your rate is documented and compliant.
4. Scale up gradually (`-t 20`, `-t 40`) only if the target stays healthy. Verify: no new timeouts appear at each step.
5. Record the final `-t` and `--timeout` in your notes. Verify: the run is reproducible.

## Variant phrasings
### gobuster concurrent requests timeout
Compact phrasing.
### gobuster -t too high error
Flag-oriented search.
### gobuster max concurrent requests exceeded
Alternate wording.

Compatibility: gobuster v3.x. `-t` (threads) and `--timeout` are stable flags.

## Why it happens
Each concurrent request holds a connection; too many at once exhausts the target's connection pool, your file descriptors, or trips rate limiting, and the slowest requests start timing out. Gobuster surfaces this as a concurrency error rather than letting the run degrade silently.

## Edge cases / pitfalls
- The "right" concurrency depends on the target, not your box. A fragile app wants `-t 5`; a CDN-fronted one takes `-t 100`.
- Raising `--timeout` too far on a dead target makes a bad run take forever. Tune both together.
- Engagement rate caps override performance tuning. When in doubt, go slower and note why.
- Watch for WAF rate rules that kick in after N requests; the first 500 requests succeeding does not mean the next 5000 will.
- On a shared lab network, coordinate scan windows with other testers; two aggressive scans at once look like one broken target.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3gc8Gx4958AAJ07DYqJ-Lg