Escalations

Configure automatic escalation so incidents never fall through the cracks.

Overview

Escalation policies ensure that incidents get attention even when the primary responder doesn’t acknowledge. Runframe automatically escalates unacknowledged incidents based on SLA deadlines and configurable rules.

Why escalation matters

How escalation works

Automatic escalation triggers

Runframe escalates when:

Escalation levels

Runframe supports multiple escalation levels:

Setting up escalation policies

Create an escalation policy

1. Navigate to Settings → Escalations
2. Click New Escalation Policy
3. Configure the policy:
   • Name: e.g., “API Backend Escalation”
   • Services: Which services this policy applies to
   • Escalation levels: Who to notify and when
4. Click Create Policy

Escalation policy example

API Backend Escalation Policy

Severity-specific overrides

Adjust escalation timing based on severity:

Escalation paths

Linear escalation

The most common pattern—escalate sequentially:

Primary on-call → Backup → Service lead → Manager → Executive

Branching escalation

For complex organizations, escalate to different people based on issue type:

Time-based escalation

Escalate to different people based on time of day:

Manual escalation

Sometimes you need to escalate before automatic policies kick in.

Request escalation from Slack

From any incident channel:

/inc page

This pages the on-call for the current incident’s services. For more control:

/inc escalate @username

Directly assign and notify a specific person.

Escalate to service lead

When stuck, escalate to the person who knows the service best:

/inc escalate --role lead

Manager escalation

For incidents needing leadership visibility or decision-making:

/inc escalate --role manager

Escalation notifications

Runframe uses multiple channels to ensure escalations are seen.

Notification channels by escalation level

Escalation messages

When an incident escalates, Runframe sends:

• Incident details – Title, severity, customer impact flag
• Current status – How long since incident creation/acknowledgment
• Why escalated – Which SLA was breached or why manually escalated
• Action needed – “Please acknowledge” or “Please take over”

Example escalation notification:

ESCALATED: INC-042 - Database connection pool exhaustion

Severity: P1 | Customer Impact: Yes
Time since creation: 25 minutes
Escalation reason: Acknowledgment SLA breached (15 min)

Primary on-call @alice has not acknowledged.
Please acknowledge this incident and take over.

Escalation best practices

Designing escalation policies

Do:

• Keep it simple – 3 to 4 levels max
• Use timezones – Consider distributed teams
• Test regularly – Verify escalation paths work
• Document clearly – Everyone should know the escalation path

Don’t:

• Don’t over-escalate – Not every incident needs executive visibility
• Don’t create bottlenecks – Avoid escalating the same person for multiple services
• Don’t ignore time off – Escalation should respect on-call overrides
• Don’t set and forget – Review and update policies quarterly

During escalation

For the person being escalated to:

• Acknowledge immediately – Even if just “On it, will update in 5”
• Assess the situation – Read the incident channel, check current status
• Introduce yourself – Let the team know you’re taking over
• Decide on next steps – Continue investigation, delegate, or rally support

For the person escalating:

• Provide context – Summarize what you’ve tried so far
• Be available – Don’t disappear after escalating
• Transfer ownership – Update incident assignments to the escalated person
• Document the handoff – Note why and when escalation occurred

Post-incident review

After escalations, review:

• Was escalation necessary? – Could the primary responder have handled it?
• Was escalation timing appropriate? – Too early, too late, or just right?
• Did the right person get escalated to? – Should the escalation path change?
• What can be improved? – Training, runbooks, or system changes?

Use these insights to refine escalation policies.

Escalation analytics

Track escalation metrics to improve your policies:

View metrics in the Analytics section of the dashboard.

Examples

Example 1: Simple linear escalation

Startup API Escalation Policy

Example 2: Severity-based escalation

E-commerce Platform Escalation Policy

Example 3: Service-specific escalation

Multi-service Organization

Need more?

• Incidents – Incident lifecycle and severity
• On-Call – Scheduling and rotations
• Slash Commands – Complete /inc command reference
• Web Dashboard – Full escalation policy management UI