Incident response

Escalation policies

Decide who gets paged, in what order, and how long to wait before trying the next person.

An escalation policy is the plan for who to try, in what order. It’s the phone-tree script WarnFire follows when an incident opens.

You’ll find them under On-call → Policies.

Before you begin

You need tenant-owner or tenant-administrator access. Create at least one responder or schedule before creating the policy. The policy cannot page a target that does not exist.

Create an escalation policy

1. Open On-call → Policies.
2. In New policy, enter a name.
3. In the first escalation step, choose Person, Schedule, or Team, then select the target.
4. Set Wait (seconds). This is how long WarnFire waits before starting the next step.
5. Set Continue while:
   • not acknowledged stops the policy when a responder takes ownership;
   • not resolved continues until the monitoring condition resolves.
6. Select the delivery channels for the step.
7. To page targets together, select + Notify another target. To add a later step, select + Add escalation step.
8. Select Create policy.

The new policy appears in the policy list with its ordered steps, wait times, continuation condition, and channels. It cannot receive incidents until a service uses it .

Verify it worked

1. Confirm that the policy appears under On-call → Policies with an enabled badge.
2. Read each displayed step in order and confirm the target, wait, continuation condition, and delivery channels.
3. Confirm that every schedule target currently has coverage and every person or team target is enabled.
4. If the policy has a fallback, confirm that it targets a genuinely different responder set from the first step.

How a policy is built

A policy is a numbered list of steps. Each step says three things:

1. Who to page. A step can target a person, schedule, or team. One step can page several targets at once — press + Notify another target to fan out.
2. How long to wait before this step gives up and the next step starts (the Wait field, in seconds).
3. When to stop. Each step continues either while not acknowledged (most common — paging stops once someone takes ownership) or while not resolved (keep escalating until the problem is actually fixed — for alerts so serious that “I’ve seen it” isn’t enough).

A typical starter policy:

Target resolution is exact:

The resolved plan is frozen on the incident. Later edits affect new incidents, not one already open. Fan-out can contact several destinations; each selected SMS or voice delivery consumes allowance or prepaid credits per destination.

How each person is paged

WarnFire uses only the channels selected for the step. The Wait value is the total time allocated to that step, including the channel ladder:

1. If push is selected and at least one device accepts it, push gets the first acknowledgement window: up to two minutes, capped at half of the step’s wait time.
2. If the incident still meets Continue while, selected email and SMS deliveries start together. If push is not selected or no push destination accepts the notification, this first window is skipped and email/SMS start immediately.
3. If voice is selected and the incident is still active, voice follows after another bounded window within the same step.
4. When the step’s total wait time expires, WarnFire starts the next step if its continuation condition still applies.

Push and email are free. SMS and voice consume allowance or prepaid credits for each destination contacted.

Things WarnFire quietly protects you from

• Editing mid-incident: changing a policy never changes an incident that’s already paging. The plan was snapshotted when the incident opened.
• An unreachable step: if a step’s responder can’t be paged (say, their contact is gone), WarnFire records that on the timeline and moves on to the next step. One broken link never silences the whole tree.
• Breaking a live service: you can’t delete a policy that a service still depends on. Disable the service first, or point it at another policy.

When the tree runs out

If every step finishes and nobody acknowledged, the incident is marked escalation exhausted. It stays open and prominent in the console and app — a signal your policy may need another step or more people.

Next step

Create a service and integration key , then select this policy for the service.