## TL;DR
The export hit a hard row cap, which is why it stops at a round number like 50k. Page the underlying API instead of relying on the UI export, or split the UI export into smaller time ranges and merge.

```text
SSO log export failed: truncated at 50k rows
```

## Use this when
- Log exports consistently stop at the same round row count.
- The UI export cannot cover the needed window.
- An audit needs complete log coverage.

## Not for this skill when
- The export errors out instead of truncating. That is a failure, not a cap.
- The API also caps at the same number. Then time-slicing is the only path.
- The logs are simply not there. That is retention, not truncation.

## Steps
1. Confirm the truncation point is consistent across runs. Verify: a round number means a cap, not a flaky failure.
2. Switch to the API with pagination. Verify: the first pages return.
3. Alternatively, split the UI export into smaller time ranges. Verify: each range completes.
4. Merge the parts and dedupe by event ID. Verify: no duplicates from overlapping ranges.
5. Check the total exceeds the old cap. Verify: coverage is complete.

## Variant phrasings
### log export row limit
The cause-first phrasing.
### truncated export
The short search.
### 50k row limit
The number-first phrasing.

Compatibility: Any SSO or audit-log export with UI row caps.

## Why it happens
UI exports are capped for browser safety; the cap is a product decision, not a bug. The API is the bulk path and paginates past the UI limit.

## Edge cases / pitfalls
- APIs with their own lower page limits; page patiently rather than assuming one call.
- Dedupe needed when time slices overlap at the edges.
- The cap changing between product tiers; the fix still works, only the numbers move.
- Timezone handling shifting events across slice boundaries; overlap and dedupe.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fsOVwheSCDd-3aJ_bLmvEA