PagerDuty Events API HTTP 429 rate limited in CI

By Daniel Zoghalchali·Latchkey

The PagerDuty Events API throttles per integration key and returns HTTP 429 when too many events arrive in a short window. In CI this happens when a matrix build triggers an event per leg, or a flapping job re-triggers rapidly instead of using a stable dedup_key.

What this error means

Trigger events return HTTP 429 with a rate-limit message. Some incidents are created and others are dropped, correlated with bursts from parallel jobs.

< HTTP/1.1 429 Too Many Requests
{"status":"throttled","message":"Requests for this service are arriving too quickly. Please retry later."}

Common causes

Matrix fan-out triggers many events

Each matrix leg firing its own trigger event exceeds the per-key rate limit in a short burst.

Rapid retries without deduplication

Re-triggering the same alert without a shared dedup_key multiplies event volume instead of updating one incident.

How to fix it

Deduplicate with a stable dedup_key

1. Use a dedup_key tied to the workflow run or service, not per leg.
2. Repeated triggers with the same key update one incident rather than creating many.
3. Send resolve events with the same key when the build recovers.

jq -n --arg k "$PAGERDUTY_ROUTING_KEY" --arg d "ci-${GITHUB_RUN_ID}" '{
  routing_key:$k, event_action:"trigger", dedup_key:$d,
  payload:{summary:"CI failed",source:"github-actions",severity:"error"}}'

Trigger once from a final job

Aggregate matrix results and send a single Events API call from a summary job.

alert:
  needs: [test]
  if: failure()
  runs-on: ubuntu-latest
  steps:
    - run: ./scripts/pagerduty-trigger.sh

How to prevent it

• Send one deduplicated event per workflow run, not per matrix leg.
• Back off before retrying a 429.
• Use dedup_key so retries update a single incident.

Frequently asked questions

Related guides

References

• GitHub Actions documentation