# Alert lifecycle

> How Firewatch turns an incoming signal into an owned incident response.

This is the machine-readable version of this Firewatch documentation page.

Firewatch separates the signal that something happened from the decisions
needed to reach and coordinate the right responder.

## 1. Ingest

An alert source sends a versioned request with an organization API key.
Firewatch applies authentication, idempotency, and correlation before the alert
event changes response state. The normalized endpoint does not add a second
inbound HMAC scheme: an adapter must validate any provider-specific signature
before it submits the normalized event.

## 2. Resolve ownership

The affected service selects an escalation policy. A step can resolve the
current responder from an on-call schedule, all primary service owners, or all
service owners. Schedule targets honor the schedule time zone, participant
effective dates, weekday coverage, and active overrides when the step becomes
due.

## 3. Deliver

At each due step, Firewatch attempts every deployment-enabled channel available
for the target: email, Slack DM, SMS, optional voice, and each enabled
organization outbound webhook. Each attempt remains independently observable,
so one provider failure does not erase the incident or prevent other channels
from being attempted.

## 4. Escalate or acknowledge

Acknowledgement assigns visible ownership. If nobody acknowledges before the
next relative delay expires, the policy advances without rewriting history.
Acknowledging or resolving records later queued steps as skipped.

## 5. Coordinate and learn

The incident timeline, responders, runbooks, and delivery attempts preserve a
single operational record. Templates can make delivery channel-specific while
keeping the underlying incident facts consistent.