On-Call
A feature that turns monitor notifications into "which person on duty right now, and in what order." It runs rotas (schedules), escalation policies, and pages on the same screen as monitoring, and pricing is decided by seats for the number of people who receive pages.
What it does
It turns notifications from monitors, incidents, and security signals into calls called "pages" and delivers them to the person in charge via push notification / email / SMS / phone call, following each team's rota (schedule) and escalation policy. If there is no response it escalates to the next step, and when the monitor recovers the page is returned to resolved.
When to use it
Use it when you want to end the state of "alerts flow into Slack, but who watches them at night is not decided." You can build operations such as rotating the duty weekly, escalating to a secondary responder if the primary does not respond in 5 minutes, and sending low-urgency notifications by email only so as not to disturb sleep, entirely within Datadog.
An everyday analogy
It is the emergency contact chain of a condominium management company. Who is on duty this week, who to pass it to next if the duty person does not pick up within a few minutes, and whether to call by phone or settle it by email are decided on one sheet of paper, and when a report from a resident (a monitor notification) comes in, people are called in the order of that chain. What is distinctive about Datadog On-Call is that the contact chain lives in the same place as the monitoring screen.
Bottom line - run rotas and pages on the same screen as monitoring, and pay per person
The last step of monitoring is "who does it reach?" Even if a monitor fires correctly, if the destination is a mention to everyone in a channel, nobody wakes up in the middle of the night. Datadog On-Call is the feature that fills this last step: when a notification occurs, it sends a "page" to a team and delivers it all the way to an individual's phone or app, following the rota and escalation policy (as of September 2026, source: On-Call). Because you can hold the rota and paging rules in the same place as the monitor configuration screen, there is no longer any need to manage "the conditions for firing" and "the destination" in duplicate across separate tools. Pricing is decided not by the number of monitored machines but by the number of people on the receiving side, that is, the seat count. Below we walk through the parts one by one and finish by confirming "who counts as a seat" and the unit price.
The 5 concepts fit together around the team
The official documentation lists 5 concepts, and at the center is the team. When a notification occurs, a page is sent to the designated On-Call team and reaches people according to the escalation policy and schedule the team owns (as of September 2026, source: On-Call).
| Concept | Role | Example |
|---|---|---|
| Page | The unit of a call. It has 3 states: Triggered / Acknowledged / Resolved | Notifications from monitors, incidents, and security signals |
| Team | The organizational unit that receives pages. It owns escalation policies and schedules | Payments team, platform team |
| Routing rules | Decide the urgency of an incoming notification and route it to a different escalation policy depending on content. Support hours can also be set to delay escalation outside those hours | Escalate notifications from the staging environment only during business hours |
| Escalation policy | The rules for in what order, and to whom, a page is escalated | Primary on-call, then secondary on-call, then the whole team |
| Schedule | The timetable of who is on duty when. It handles time zones and rotations | A weekly-rotating primary on-call rota |
What makes this structure easy to remember is that there is one level of abstraction: you do not call a person directly, you "call the team." The monitor side knows only the team's name, and the duty roster and order beyond that are self-contained within the team. It is thanks to this one level that you never have to touch monitor configuration for staff changes or rota handovers.
The @oncall- handle connects monitors to pages
Connecting to monitors takes just 1 format. Mention a team's handle with oncall- prefixed and a page is sent to that team. For a team whose handle is @checkout-operations, it is @oncall-checkout-operations. This format works not only in monitors but anywhere @ mentions can be used, such as Incident Management, security detection rules, and event management (as of September 2026, source: Pages). Urgency, when sent from a monitor, is decided by the threshold when the team's routing rules use dynamic urgency, and is always high when sent manually or from Slack. The behavior on recovery and renotification is summarized in the table below (source: same as above).
| Event | Page behavior |
|---|---|
| Monitor ALERT threshold crossed (when the team's routing rules use dynamic urgency) | Becomes a high-urgency page |
| Monitor WARN threshold crossed (same condition) | Becomes a low-urgency page |
Manual send from the Datadog UI, or send from Slack's /datadog page | Always high urgency |
| Recovery (the recovery notification body contains the team mention) | Automatically becomes Resolved |
Recovery (the mention exists only inside an {{#is_alert}} conditional block) | Not automatically resolved |
| Renotification (page is resolved) | Creates a new page and runs it through the escalation policy |
| Renotification (page is acknowledged) | Resumes escalation from the step at which it was acknowledged |
| Renotification (unacknowledged after all steps have finished) | Starts over from the first step |
The structure of notification text is covered in the Monitors explainer, so here remember just 1 point: "put the mention outside the conditional block." It is a design in which an alert does not end after firing once but keeps following up until a person acts.
Escalation policies are written in steps, wait times, and repeats
An escalation policy is the rule that escalates a page to the next step if it is not acknowledged within the time limit. There are 3 things to decide per step: whom to notify (individuals, a team, or the person on duty in a schedule), how to notify (Notify All or Round Robin), and how many minutes to wait before escalating to the next step. For the policy as a whole, you decide how many times to repeat the steps when nobody acknowledges, and whether to automatically set the page to Resolved after all steps and repeats have finished (as of September 2026, source: Escalation Policies).
- Step 1: notify the person on duty in the "primary on-call" schedule (Notify All), then move on if not acknowledged
- Step 2: notify the person on duty in the "secondary on-call" schedule plus 1 individual, then move on if not acknowledged
- Step 3: notify the whole team
- Repeat: if still unacknowledged after all steps, start over the decided number of times
- End: choose whether to automatically set to Resolved after the repeats finish, or leave it open
Notify All notifies everyone targeted by the step at the same time; in the official example, a step containing 1 individual, a team of 3, and 1 schedule reaches 5 people. Round Robin cycles through targets in turn, but if there is no acknowledgment within the time limit it does not go to the next person in the same step and instead escalates to the next step, so if you want to cycle in turn, place just 1 Round Robin step and set it to repeat more times than the number of people (source: same as above).
Through which channels do pages arrive, and who decides
There are 4 channels through which a page reaches an individual: push notifications from the Datadog mobile app, email, SMS, and phone call. SMS does not support landlines, VoIP, or virtual numbers, and phone number support varies by country (as of September 2026, source: Notification Preferences). The receiving channels are decided per urgency by the recipient themselves, not by an administrator. For high urgency, immediate push notifications and phone calls are recommended as the main channels (the official example is push notification, then a phone call 1 minute later, then another push notification 2 minutes later), and low urgency can be set to email only without escalation. When a high-urgency page arrives for someone who has configured nothing, email automatically serves as the fallback (source: same as above). The escalation policy decides "how many minutes until the team escalates to the next step," while notification preferences decide "through which channel I want to be woken." Keeping the operational agreement and personal circumstances separate is what makes a rota last. If you stop monitor notifications with a downtime during planned maintenance windows, no pages are sent either.
How organizations already using PagerDuty should think about it
For organizations already operating a paging tool such as PagerDuty, the question is whether On-Call is "one more tool" or "a replacement." The official documentation states 2 facts. One is that when creating an On-Call team, in addition to creating new and adding an existing Datadog team, there is an option to import team settings from PagerDuty. The other is that, in order to preserve history, deletion of pages, escalation policies, and schedules is not supported, and creating a trial organization as a sandbox is the recommended way to try things without affecting production (as of September 2026, source: On-Call). Drawing a line of reasoning from these 2 points gives the following order.
- 1. Create a trial organization, import team settings from PagerDuty, and confirm how faithfully rotas and policies are reproduced
- 2. Move teams that reproduced correctly to the production organization. During the migration period the same monitor sends notifications to both, so switch team by team: "starting this week, this team's paging is On-Call"
- 3. Leave notifications that remain in the external tool on their existing routes such as Webhooks, and replace only the switched teams with @oncall- mentions
The major motivation for migrating is that the monitor that fired, the person on duty, and the acknowledgment and resolution history all line up on one screen. The disconnect where acknowledging a page in the paging tool leaves nothing on the monitor screen disappears.
Pricing is decided by the number of seats - who counts
On-Call is seat-based billing, and a seat is "a license for a user who actively participates in on-call or incident response." A user needs an On-Call seat if they do any of the following: are in a schedule, are included in an escalation policy, or have notification preferences configured to receive pages. Merely viewing existing pages, policies, teams, and schedules does not require a seat (as of September 2026, source: Incident Response Billing).
| SKU | Billing unit | Contract form | What is included | Points to note |
|---|---|---|---|---|
| On-Call alone | Seat / month | Three columns with different unit prices: annual contract, monthly contract, and on-demand | Rotas, escalation, pages | Seats beyond the contracted count are counted at the on-demand unit price |
| Incident Response bundle | Seat / month | The same three-column structure | On-Call + Incident Management | A single SKU that holds the seats for both On-Call and Incident Management |
The key point of counting is "maximum concurrent assignments." Once a user acquires a seat, billing continues monthly until it is released, and a person removed partway through the month still remains billable for that month (source: same as above). In practice, "people in the rota + people in the final escalation step" is the lower bound of the seat count, and view-only people are not counted. For where this sits within overall pricing, see the pricing guide.
The order of design starts from "who receives"
If you start from the parts, you get stuck in the details of schedule rotations and routing rules. Reverse the order and line up 3 questions to answer.
- Who receives: decide 1 team and list the people who go into the primary on-call schedule. That headcount is the lower bound of seats
- When to escalate: decide how many minutes without a primary response before escalating to secondary, and transcribe it into the escalation policy's steps and wait times
- What to act on: narrow the monitors connected to pages to only those that deserve high urgency, and make the rest low or no page
The third of these matters most. If too many monitors are connected to pages, the person on duty becomes someone who just presses the acknowledge button, and escalation becomes a device that carries "notifications nobody seriously looks at" upward. The means to reduce alert fatigue on the monitor side are in that explainer, so on the On-Call side, first put in place the 1-line rule "connect to high only what requires a person to act right now." Once the 3 questions are answered, routing rules can wait. Running the minimum configuration of 1 team, 1 schedule, a 2-step policy, and only high connected to pages for 1 month, then expanding after looking at time to acknowledgment and the number of escalations, is the order that makes a rota last.
Things to watch out for
- This article is based on the official documentation as of September 2026. The countries supported by notification channels, the handle format, and the definition of operations that require a seat may change, so check the official documentation before configuring.
- This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
- Seat count is counted as the maximum concurrent assignments during the billing period, and users released partway through the month still remain billable for that month (as of September 2026). Decide the number of people in the rota before deciding the contracted seat count.