Escalation Policies

An escalation policy makes sure an incident that nobody acknowledges keeps climbing the chain until someone responds. Instead of a single alert that can be missed, the policy fires a sequence of steps over time -- each step reaching a wider or different audience -- and stops the moment the incident is acknowledged.

Escalation policies are most useful for critical, customer-facing services where a missed alert in the middle of the night isn't acceptable.

How Escalation Works

When an incident is created, its notification rule sends the first round of alerts as usual. If a policy is attached and the incident is not acknowledged in time, Hoppla begins working through the policy's steps:

1. Each step waits its configured time, then notifies its target.
2. As long as the incident stays unacknowledged (and unresolved), Hoppla continues to the next step.
3. Once someone acknowledges the incident -- or it resolves on its own -- escalation stops immediately. No further steps fire.

This guarantees that a serious incident reaches a real person, while a quickly-handled one never escalates past the first alert.

Steps

A policy is an ordered list of steps. Each step has:

• Wait time -- How many minutes to wait before this step fires (measured from when escalation started). For example, a step with a 10-minute wait notifies its target 10 minutes into an unacknowledged incident.
• Target -- Who to notify. A step can point at either:
  • A notification channel (e.g. a Slack channel, an email address, a PagerDuty service), or
  • An on-call schedule -- which pages whoever happens to be on call at that moment.

A typical policy starts gentle and grows more urgent: notify the team chat after 5 minutes, page the on-call engineer after 15, page a backup after 30.

Repeating the Policy

Beyond the individual steps, a policy can repeat the whole sequence:

• Repeat count -- How many times to loop through all the steps again after the last step fires.
• Repeat interval -- How long to wait (in minutes) after the last step before each repeat begins. 0 waits as long as the steps take.

A repeat runs the steps in the same order with the same waits, counted from the start of the repeat. Example: Slack right away, PagerDuty after 10 minutes, repeat interval 0: Slack at 0, PagerDuty at 10, then Slack at 20 and PagerDuty at 30.

This is the safety net for an incident that is still unacknowledged after the final step -- the policy loops back to the beginning rather than going silent. As always, acknowledging the incident stops the loop.

Enabling and Disabling

Each policy has an enable/disable toggle. A disabled policy stays configured but is skipped -- handy for pausing an escalation path during planned work without deleting and rebuilding it.

Attaching a Policy to a Rule

Escalation policies don't fire on their own; you attach one to a notification rule:

1. Create your escalation policy and its steps.
2. Open (or create) a notification rule and use the Escalation policy field to select your policy.
3. Save the rule.

From then on, any incident that matches that rule -- and isn't acknowledged in time -- follows the policy. Different rules can use different policies, so you might escalate production incidents aggressively while leaving staging alerts as a single notification.

Acknowledge to stop escalation

Acknowledging an incident is the off-switch for escalation. Whoever picks up an incident should acknowledge it (from the incident detail page) so the rest of the team -- and the on-call rotation -- aren't paged unnecessarily.