Escalation Patterns

Ready-to-use escalation recipes for common MSP on-call and incident response scenarios.

Pattern 1 — Acknowledge or escalate (5-minute rule)

The most common MSP escalation: notify the primary engineer, wait 5 minutes, escalate if unacknowledged.

Trigger: Alert Firing
  ├─ Condition: Severity in [critical, high]
  │   True:
  │     ├─ Notify: SMS → Primary on-call
  │     ├─ Delay: 5 minutes
  │     └─ Condition: Alert Status = firing  ← still unacknowledged
  │         True:
  │           ├─ Notify: SMS → Secondary on-call
  │           ├─ Notify: Voice call → Primary on-call
  │           ├─ Delay: 10 minutes
  │           └─ Condition: Alert Status = firing
  │               True:
  │                 └─ Notify: SMS → Manager
  └─ False: (stop)

Build this:

  1. Add Condition → Severity in [critical, high]
  2. On True: Add Notify (SMS, primary on-call)
  3. Add Delay (5 min)
  4. Add ConditionStatus = firing
  5. On True: Add Notify (SMS + Voice, secondary)
  6. Add Delay (10 min)
  7. Add ConditionStatus = firing
  8. On True: Add Notify (SMS, manager)

Pattern 2 — Business hours vs. after-hours routing

Route to Slack during business hours; go directly to SMS/voice after hours.

Trigger: Alert Firing
  ├─ Condition: Severity in [critical, high]
  │   True:
  │     ├─ Condition: Is business hours = true
  │     │   True:  Notify → Slack #alerts
  │     │   False: Notify → SMS (on-call) + Voice call
  │     └─ (both branches: wait 15 min, then re-check)
  └─ False: Notify → Slack #alerts-low (severity medium/low)

Pattern 3 — Client-tier SLA routing

Different clients have different SLAs. Route premium-tier clients to faster escalation.

Trigger: Alert Firing
  ├─ Condition: Label "tier" = "premium"
  │   True:
  │     ├─ Notify: SMS → On-call (immediate)
  │     └─ Create Ticket (ConnectWise, Priority 1)
  ├─ Condition: Label "tier" = "standard"
  │   True:
  │     ├─ Notify: Slack #alerts
  │     ├─ Delay: 15 minutes
  │     └─ Condition: Status = firing
  │         True: Notify → SMS → On-call
  └─ Condition: Severity = critical  ← fallback for untagged clients
      True: Notify → SMS → On-call
Tip

Set client tier labels on alerts by configuring the client label in your integration field mappings, then use a separate workflow (or a second condition branch) to tag with tier.


Pattern 4 — Ticket-first (low-noise environments)

For MSPs that want everything in the PSA ticketing system and only page for truly critical issues:

Trigger: Alert Firing
  ├─ Create Ticket (ConnectWise / Kaseya)
  ├─ Condition: Severity = critical
  │   True:
  │     ├─ Notify: SMS → On-call
  │     └─ Delay: 3 minutes
  │         └─ Condition: Status = firing
  │               True: Voice call → On-call
  └─ Condition: Severity = high
      True: Notify → Slack #alerts

Pattern 5 — Flap suppression

Monitors that flip between firing and resolved rapidly create noise. Suppress after 3 flaps.

Trigger: Alert Firing
  ├─ Condition: Flapping Count >= 3
  │   True:  Suppress alert + Notify Slack (flapping suppressed)
  └─ False:  Continue normal escalation

Pattern 6 — All-quiet night shift

During a maintenance window or on weekends, suppress low/medium alerts entirely and only escalate critical.

Trigger: Alert Firing
  ├─ Condition: Day of week in [Saturday, Sunday]
  │   True:
  │     └─ Condition: Severity = critical
  │         True:  Normal escalation chain
  │         False: Suppress automatically
  └─ False: Normal escalation chain (weekday)
Note

You can also use a Suppression Window (Settings → Suppression) for scheduled maintenance. Suppression windows apply before any workflow runs, so they're more efficient for large-volume events.


Pattern 7 — Digest (bulk summary)

Instead of individual SMS per alert, collect all firing alerts over 30 minutes and send one summary.

Trigger: Schedule — every 30 minutes
  ├─ HTTP Request: GET /api/v1/alerts?status=firing&limit=50
  └─ Condition: Response count > 0
      True: Notify → Email → On-call
            (Subject: "{{count}} firing alerts — review required")
Note

The scheduled trigger workflow uses the full API context of your organization. The HTTP Request node can call AlertFlow's own API using your org's API key stored in a workflow variable.


Tips for MSPs

  • Name workflows by use case: "Critical — 5-min escalate", "Maintenance → Suppress", "Contoso — Premium SLA". This makes the workflow list scannable.
  • Use execution logs: Every failed SMS or voice call is logged with the exact error. Check here before blaming the integration.
  • Test with synthetic alerts: Use the Test button to fire a workflow with any severity/status without creating real alert noise.
  • Clone before editing: Use the Duplicate option in the workflow menu to clone before making changes to a production workflow.