## TL;DR
The agent's incident creation was throttled, which means the page may not have gone out: the worst possible notification to lose. Retry with backoff and confirm the incident exists by reading it back; if creation keeps failing, escalate through the fallback channel immediately. An unconfirmed page is an unsent page.

```text
pagerduty API 429 when agent tried opening an incident, request failed
```

## Use this when
- Agent PagerDuty incident creation hits 429.
- It is unclear whether the incident was created.
- The underlying issue still needs a human.

## Not for this skill when
- Read-only PagerDuty calls get throttled. Back off, but no page is at risk.
- Incident creation returns other errors. Handle those specifically.

## Steps
1. Back off on the 429 and retry the creation with jitter. Note the retries. Verify: transient throttles are absorbed
2. Read back the incident list to confirm whether the incident exists: the first attempt may have succeeded. Note the check. Verify: duplicate versus missing is decided
3. If it exists, use it; if not, create it once the throttle clears. Note the outcome. Verify: exactly one incident exists
4. If creation keeps failing, page through the fallback channel now. Note the fallback page. Verify: the human is reached regardless
5. Log the throttled window and review whether the agent's call rate needs a permanent cap. Note the review. Verify: the pattern is addressed

## Variant phrasings
### pagerduty 429 incident creation
The code-shaped search.
### pagerduty api rate limit retry
The technique phrasing.

Compatibility: PagerDuty REST API rate limits. Incident creation and retrieval are the relevant endpoints.

## Why it happens
Incident creation is the one API call where failure is an emergency: a throttled page is a human who never gets woken up. The 429 ambiguity is nasty because the throttled request may or may not have executed, so blindly retrying can create duplicate incidents while not retrying can lose the page. Read-back confirmation resolves the ambiguity, and the fallback channel exists for when the API simply will not cooperate. Deduplication keys on the incident make retries safe.

## Edge cases / pitfalls
- Use a deduplication key on incident creation so retries cannot create duplicates. The key is the safety net.
- A 429 storm during a major incident throttles every integration at once. The fallback channel must not depend on the same API.
- Confirming by read-back needs the right query: search by dedup key, not by recency.
- Log every page attempt with its outcome. Paging disputes are settled by logs, not memory.

## Provenance

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