## TL;DR
The AJAX spider drives a real browser through clickable elements, and modern apps generate endless states: calendars, carousels, infinite scroll, and per-user routes. It never finishes because the state graph never ends. Bound it with a maximum crawl duration and depth, exclude the elements that generate states, and treat its output as a URL harvest to hand to the rest of the assessment.

```text
zap ajax spider never finishes on javascript-heavy authorized app
```

## Use this when
- An AJAX spider run against an authorized SPA has run far beyond its planned window with the URL count still climbing.
- The app has calendars, infinite lists, or generated routes that create new states forever.

## Not for this skill when
- The crawl is slow but the state count is levelling off. Let a bounded crawl finish rather than restarting it.
- The app is mostly server-rendered pages. The traditional spider is faster and more predictable there.

## Steps
1. Stop the current run and keep its discovered URLs; they are valid coverage even though the crawl did not formally finish. Verify: Verify: the sites tree retains the URLs found so far.
2. In the AJAX spider options, set a maximum duration and a maximum crawl depth that match the engagement timebox. Verify: Verify: both limits show the values you chose, not the defaults of effectively unbounded.
3. Add exclusions for state-generating elements and URL patterns, such as date pickers, next-page carousels, and sort or filter combinations, based on what the first run exploded on. Verify: Verify: the exclusion list names the patterns observed in the runaway crawl.
4. Reduce concurrent browsers if the tester box is struggling, since each AJAX spider browser is a full browser process. Verify: Verify: system memory stays stable during the rerun.
5. Rerun the bounded crawl and export the discovered URL list when the limit stops it, recording that coverage was timeboxed. Verify: Verify: the crawl ends by limit, and the exported list feeds the active scan plan.

## Variant phrasings
### zap ajax spider maximum duration depth settings
The settings phrasing.
### ajax spider infinite scroll calendar endless states
The root-cause phrasing.
### zap ajax spider out of memory many browsers
The resource phrasing.

Compatibility: Compatibility: OWASP ZAP 2.x AJAX spider with its bundled browsers; crawl state counts vary by add-on version.

## Why it happens
The AJAX spider explores by interacting, and it stops when it runs out of new states. Reactive apps mint states combinatorially: every filter, page, and date multiplies routes, and client-side routing means there is no server 404 to prune the tree. Without explicit bounds the correct behaviour of the tool is, unfortunately, to crawl forever.

## Edge cases / pitfalls
- Timeboxed coverage must be disclosed in the report; unexplored app states are a limitation, not a clean result.
- Some states only appear for particular roles; run bounded crawls per test role rather than one endless crawl.
- Watch for AJAX spider clicks that trigger real actions like sending mail or deleting items; exclude action elements on anything but a dedicated test tenant.

## Provenance

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