Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt

Use this file to discover all available pages before exploring further.

When you create an incident with an escalation policy attached, Scaling automatically pages the on-call responder for the first layer of that policy. If no one acknowledges within the layer’s timeout, Scaling moves to the next layer and pages there. This page explains the paging flow end-to-end so you can predict who will be notified and when.
Paging notification

​
The paging flow

Incident created (with escalationPolicyId)
        │
        ▼
   Layer 1 paged ──► notification sent (email + Slack DM if connected)
        │
        ▼
   Wait ackTimeoutMinutes
        │
        ├── Acknowledged ──► escalation stops
        │
        └── Not acknowledged ──► Layer 2 paged ──► …continue down the chain
  1. Layer 1 pages immediately. Scaling looks up the layer’s target — either a schedule or a fixed list of users — and notifies the resolved on-call responder(s).
  2. A timeout is scheduled. If the layer specifies ackTimeoutMinutes, Scaling schedules an escalation event for that time in the future.
  3. Acknowledgment cancels the timeout. When a responder acknowledges (from the dashboard, the API, or Slack), the scheduled escalation is cancelled and the incident stops moving down the chain.
  4. Otherwise, the next layer fires. When the timeout elapses without acknowledgment, Layer 2 is paged and its own timeout is scheduled. This continues until either someone acknowledges or all layers have been exhausted.

​
Notification channels

When a layer fires, Scaling notifies the resolved responder(s) on every channel they have available:
  • Email — sent to the email address on the responder’s Scaling account.
  • Slack DM — sent when the responder’s email matches a member of your connected Slack workspace. The DM includes Acknowledge, Resolve, and View Incident buttons. See Slack integration.
  • Incident channel mention — if your workspace has incident channels enabled, the on-call responder is auto-invited and pinged in the dedicated channel for the incident.
Email is always sent. Slack notifications are sent in addition when the integration is installed and the responder’s email matches a Slack user in your workspace.

​
Audit trail

Every paging-related event is recorded on the incident’s audit trail, including:
  • escalation_triggered — a layer was reached and the responder was notified.
  • notification_dispatched — a notification was successfully delivered.
  • incident_acknowledged — a responder acknowledged the page.
  • incident_handed_off — ownership was transferred to another team member (see Acknowledgment & handoff).
  • escalation_exhausted — every layer has been notified and none acknowledged.
You can view the audit trail on the incident detail page in the dashboard, or fetch it via the API alongside the incident record.

​
What stops paging?

Once any of the following happens, Scaling stops paging on the incident:
  • A responder acknowledges the incident.
  • The incident is moved to resolved status.
  • The incident’s escalation policy is detached by updating escalationPolicyId to null.
  • The policy is exhausted (every layer has been notified). The incident remains open, but no further pages are sent.
A critical incident without an escalation policy will never page anyone. Attach a policy at creation time — or, better, set a default policy on the incident form — for any severity that needs a human in the loop fast.