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
New triggers per minute — bounded by your plan. Trial keys accept up to 60 new triggers per minute, Team up to 300, Business up to 1,000, and Enterprise up to 5,000. Past the applicable ceiling, triggers get a 429 answer with a Retry-After header. Exact idempotent retries do not consume the allowance. Resolve and acknowledge events remain available, so recovery traffic is never trapped behind a trigger storm.
You can set a lower per-key trigger limit while adding a key to an existing service . A key-specific value is a safety cap; it cannot raise the plan ceiling. Use separate keys for independent monitoring sources so one noisy sender does not consume another sender’s allowance.
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 under Configuration → Services. Follow Add a key to an existing service to apply a key-specific limit.
Integration key hygiene
Keys have their own quiet protections, visible on each service’s key list:
- Expiry — keys can be set to expire, or never expire. The console offers preset lifetimes (30, 90, 180, or 365 days). You’ll see a warning 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 The safety catch . |
429 | Rate or active-incident limit reached. | Wait for Retry-After, or resolve open incidents. |
WarnFire answers 202 only after the accepted event has been committed to its
durable event record. Treat any other response as unaccepted and retry according
to its status and Retry-After guidance.
See client_event_id
for retry behavior that does not consume another trigger slot.