## TL;DR
E0000018 means the poller blew the System Log rate limit, which is shared org-wide. Slow the poll interval to 60 seconds or more, page with the since cursor instead of re-pulling windows, and back off exponentially on 429.

```text
"E0000018 rate limit exceeded" Okta System Log polling
```

## Use this when
- System Log API calls return 429 with errorCode E0000018.
- A SIEM forwarder or audit agent polls the log on a tight loop.
- The polling worked, then started failing at busy times of day.

## Not for this skill when
- The status is 401. That is a token problem, not a rate problem.
- Events are missing but no 429 appears. That is retention or a collector gap.
- The consumer is the Okta UI rather than the API.

## Steps
1. Confirm the 429 responses carry errorCode E0000018. Verify: the failures are rate limits, not auth.
2. Add exponential backoff starting at 5 seconds and capped at 120 seconds. Verify: a 429 pauses the poller instead of hammering.
3. Poll no faster than once per minute, setting since to the last event time seen. Verify: each poll is a small incremental pull.
4. Dedupe events by their uuid before processing. Verify: overlapping windows do not double-count.
5. Watch for a full poll cycle with steady 200 responses. Verify: the limiter stays quiet for at least 15 minutes.

## Variant phrasings
### Okta API 429
The generic phrasing; System Log polling is the most common trigger.
### "too many requests" System Log
How the error reads in some client libraries.
### System Log polling best practice
The how-to phrasing for the same fix.

Compatibility: Okta System Log API (events v1), Classic and Okta Identity Engine. Rate limits are org-wide and shared across all API consumers.

## Why it happens
The System Log endpoint is expensive to serve, so Okta rate-limits it tightly and shares the bucket across every integration in the org. A poller firing every few seconds, or two pollers running at once, exhausts the bucket quickly.

## Edge cases / pitfalls
- Multiple pollers in the same org (SIEM plus your agent) multiply the load; coordinate them onto one poller.
- The until parameter encourages tight re-polling of the same window. Prefer since-based forward paging.
- Backoff without jitter can synchronize retries with the limit window; add a small random delay.
- Some SDKs retry 429s immediately by default. Disable that and use your own backoff.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_J33BF7-pS0w0QmmP3vQ5xg