Skip to main content
When you create an incident with an escalation policy attached, scaling.cloud automatically pages the on-call responder for the first layer of that policy. If no one acknowledges within the layer’s timeout, scaling.cloud 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

An on-call responder receives a page on a new incident

​
The paging flow

  1. Layer 1 pages immediately. scaling.cloud 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.cloud 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.cloud notifies the resolved responder(s) on every channel they have available, in parallel:
  • Email — sent to the email address on the responder’s scaling.cloud account.
  • SMS — sent to each verified, SMS-enabled contact method. The text carries the incident title, severity, a link that opens the incident, and a short code you can reply to acknowledge. See Acknowledgment & handoff.
  • Voice call — an automated call to each verified, voice-enabled contact method that speaks the incident. Answering acknowledges it; a call that reaches voicemail counts only as delivery and escalation continues.
  • 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 the floor — it is always sent and cannot be disabled. SMS and voice are additive opt-ins you enable on a verified contact method; Slack is 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 — the lead 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.cloud 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.