Events API

Limits and protections

The guardrails that keep a runaway monitor from flooding your team — and what to do when you hit one.

A misconfigured monitor can fire thousands of alerts in minutes. WarnFire’s guardrails make sure a flood like that can’t bury your team or your bill. Most days you’ll never notice them.

The two limits

Events per minute — 60 per key, per minute (default). Each integration key may open up to 60 new problems per minute. Past that, triggers get a 429 answer with a Retry-After header. Two things don’t count against it: repeats of already-open problems (dedup updates), and retried deliveries — so a noisy incident doesn’t eat your budget.

Need more for a busy service? Each key’s limit can be raised (up to 10,000/minute) when you create or edit it under Configuration → Services.

Active incidents — 100 per service. One service can have at most 100 incidents open at once. At the cap, new problems are turned away with 429 — but everything already open keeps working: paging continues, and acknowledging and resolving are unaffected. Resolve some incidents and the door reopens.

If 100 incidents are genuinely open at once, they’re usually one root cause wearing a hundred costumes — the fix is almost always broader dedup keys or coarser alert grouping, not a bigger cap.

Your workspace’s current values are shown on Configuration → Services (“default event limit” and “maximum active incidents”).

Integration key hygiene

Keys have their own quiet protections, visible on each service’s key list:

Expiry — keys can be set to expire (30 days to a year, or never). You’ll see a warning in the console before one lapses (7 days by default).
Unused-key warnings — a key that hasn’t sent anything in a while gets flagged, so forgotten credentials don’t linger.
Overlap-friendly rotation — Rotate creates the replacement while the old key still works, so you can update your monitoring system with zero missed alerts, then revoke the old one.
Keys are shown once at creation and stored only in disguised form (wf_live_••••8K2P) afterward.

What the answers mean

Code	Meaning	What to do
`202`	Accepted and safely recorded.	Nothing — you’re done.
`400`	The event was malformed.	Check required fields and formats.
`401`	Unknown, expired, or revoked key.	Check you’re using the right key; rotate if needed.
`403`	The workspace is suspended (usually billing).	The workspace owner can fix this under Billing.
`409`	A delivery ID was reused for a different request.	See Dedup & retries.
`429`	Rate or active-incident limit reached.	Wait for `Retry-After`, or resolve open incidents.

One promise underneath all of this: WarnFire answers 202 only after your event is durably saved. If you got a 202, the event cannot be lost.