Alert lifecycle

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.