WarnFireDocs

Core concepts

Core concepts

How WarnFire turns provider events into one durable incident, preserves lifecycle state, and pages the right responders.

Version 1.0 Status Needs verification For All users incidentseventslifecycleescalation

Monitoring systems detect alarms or alerts. A WarnFire integration normalizes each relevant state change into an event. WarnFire then separates those incoming events from the durable incident responders operate. A monitoring source can send many updates for the same problem; WarnFire correlates them into one incident so acknowledgement, paging, discussion, delivery evidence, and resolution remain attached to one record.

From an event to an incident

  1. An integration authenticates with a key bound to one workspace and one integration.
  2. WarnFire validates and normalizes the provider payload into a canonical lifecycle event.
  3. A trigger opens an incident or updates the matching open incident according to the event’s deduplication key.
  4. The incident freezes the response plan that applied when it opened.
  5. WarnFire dispatches the current escalation step and records each delivery attempt independently.

Later administrative edits affect new incidents. They do not rewrite the response plan of an incident already in progress.

Lifecycle

An incident progresses through a small canonical lifecycle: triggered, acknowledged, and resolved. Provider-specific states map onto those operations instead of creating a second lifecycle. Repeated delivery of the same event is idempotent, so a safe retry does not create a second incident or repeat the same transition.

A human acknowledgement from an authorized response surface records who took responsibility and stops pending escalation according to the incident’s frozen plan. A source-side Events API acknowledgement records evidence but does not stop paging. Resolution closes the active problem. A new trigger after resolution starts a new operational record rather than silently reopening the old one.

Paging and evidence

Schedules determine who is on call. Escalation policies determine whom to notify, which channels to use, and how long to wait before continuing. Provider acceptance and terminal delivery evidence are different facts: an accepted request is not proof that a person received or acted on it.

Continue with

Continue with Incident response for schedules and escalation, Events API for lifecycle requests, and Delivery evidence for channel-specific outcome meanings.