On-Call

結論 - 当番と呼び出しを監視と同じ画面で回し、人数で払う

監視の最後の工程は「誰に届くか」です。モニターが正しく鳴っても、届く先がチャンネル全員へのメンションなら、深夜には誰も起きません。Datadog On-Call はこの最後の工程を埋める機能で、通知が発生したときにチームへ「ページ」を送り、当番表とエスカレーションポリシーに沿って個人の電話やアプリまで届けます (2026 年 9 月時点・出典: On-Call)。モニターの設定画面と同じ場所で当番と呼び出しの規則を持てるので、「鳴る条件」と「届く先」を別のツールで二重管理する必要がなくなります。料金は監視対象の台数ではなく、呼び出しを受ける側の人数、つまりシート数で決まります。以下では部品を 1 つずつたどり、最後に「誰をシートに数えるか」と単価を確かめます。

5 つの概念はチームを中心に組み合わさる

公式ドキュメントが挙げる概念は 5 つで、中心にあるのはチームです。通知が発生すると、指定された On-Call チームへページが送られ、チームが持つエスカレーションポリシーとスケジュールに沿って人へ届きます (2026 年 9 月時点・出典: On-Call)。

この構造で覚えておくと楽なのは、人を直接呼ぶのではなく「チームを呼ぶ」という一段の抽象があることです。モニター側はチームの名前しか知らず、その先の当番や順番はチームの中で完結します。人事異動や当番の交代でモニターの設定を触る必要が無いのは、この一段のおかげです。

モニターからページへ繋ぐのは @oncall- のハンドル

モニターとの接続は 1 つの書式で済みます。チームのハンドルの前に oncall- を付けてメンションすると、そのチームへページが送られます。ハンドルが @checkout-operations のチームなら @oncall-checkout-operations です。この書式はモニターのほか、Incident Management、セキュリティ検出ルール、イベント管理など、@ メンションが使える場所ならどこでも効きます (2026 年 9 月時点・出典: Pages)。緊急度は、モニターから送る場合はチームのルーティングルールが動的緊急度を使うときにしきい値で決まり、手動や Slack から送ると常に high です。復旧と再通知の挙動も含めて表にまとめます (出典: 同上)。

通知文の構成はモニターの解説で扱っているので、ここでは「メンションを条件ブロックの外に置く」の 1 点だけ覚えてください。アラートが 1 回鳴っただけで終わらず、人が動くまで追いかける設計です。

エスカレーションポリシーは段と待ち時間と繰り返しで書く

エスカレーションポリシーは、ページが時間内に確認されなければ次の段へ上げる規則です。1 つの段で決めることは 3 つです。誰に通知するか (個人、チーム、またはスケジュール上の当番)、どう通知するか (Notify All か Round Robin)、次の段に上げるまで何分待つか、です。ポリシー全体では、誰も確認しないとき段を何回繰り返すか、全段と繰り返しを終えたあとページを自動で Resolved にするかを決めます (2026 年 9 月時点・出典: Escalation Policies)。

Notify All は段の対象全員に同時に通知し、公式の例では個人 1 名と 3 名のチームとスケジュール 1 つを含む段なら 5 人に届きます。Round Robin は対象を順番に回す方式ですが、時間内に確認が無くても同じ段の次の人には行かず次の段へ上がるため、順番に回したいなら Round Robin の段を 1 つだけ置き、人数以上の回数を繰り返す設定にします (出典: 同上)。

呼び出しはどの経路で届き、誰が決めるか

ページが個人に届く経路は 4 つで、Datadog モバイルアプリのプッシュ通知、メール、SMS、電話です。SMS は固定電話や VoIP、仮想番号に対応せず、電話番号の対応は国で異なります (2026 年 9 月時点・出典: Notification Preferences)。受ける経路は管理者ではなく受け手本人が緊急度ごとに決めます。緊急度 high には即時のプッシュ通知と電話を主経路にすることが勧められ (公式の例はプッシュ通知 → 1 分後に電話 → 2 分後に再度プッシュ通知)、low はメールだけにして上げない設定もできます。何も設定していない人に high のページが来ると、メールが自動の受け皿になります (出典: 同上)。エスカレーションポリシーは「チームとして何分で次へ上げるか」、通知設定は「自分はどの経路で起こされたいか」を決めます。運用の約束と個人の事情を分けておくと当番表が長続きします。計画停止の時間帯はダウンタイムでモニターの通知を止めれば、ページも出ません。

PagerDuty を使っている組織はどう考えるか

すでに PagerDuty などの呼び出しツールを運用している組織にとって、On-Call は「もう 1 つ増える」のか「置き換える」のかが問題になります。公式ドキュメントが記載している事実は 2 つです。1 つは、On-Call チームを作るときに新規作成と既存の Datadog チームの追加に加えて、PagerDuty からチームの設定を取り込む選択肢があること。もう 1 つは、履歴を保存するためにページやエスカレーションポリシー、スケジュールの削除に対応しておらず、本番に影響を与えずに試すには試用の組織をサンドボックスとして作ることが案内されていることです (2026 年 9 月時点・出典: On-Call)。この 2 点から判断の筋道を引くと、次の順になります。

移行する動機として大きいのは、鳴ったモニター、当番、確認と解決の履歴が 1 つの画面に揃うことです。呼び出しツール側でページを確認してもモニターの画面には何も残らない、という断絶が消えます。

料金はシートの数で決まる - 誰を数えるか

On-Call はシート課金で、シートは「オンコールやインシデント対応に能動的に参加する利用者のライセンス」です。On-Call のシートが必要になるのは、スケジュールに入っている、エスカレーションポリシーに含まれている、ページを受けるための通知設定をしている、のいずれかを行う利用者です。既存のページやポリシー、チーム、スケジュールを見るだけならシートは要りません (2026 年 9 月時点・出典: Incident Response Billing)。

数え方の要点は「最大同時割り当て数」です。利用者がシートを取得すると解除されるまで月ごとに課金が続き、月の途中で外した人の分もその月は請求対象に残ります (出典: 同上)。実務では「当番に入る人 + エスカレーションの最終段に入る人」がシート数の下限で、閲覧だけの人は数えません。料金全体の中での位置づけは料金体系の読み解きを参照してください。

設計の順序は「誰が受けるか」から

部品から始めると、スケジュールの交代制やルーティングルールの細部で止まります。順序を逆にして、答えるべき問いを 3 つ並べます。

この 3 番目が最も効きます。ページに繋ぐモニターが多すぎると、当番は確認ボタンを押すだけの人になり、エスカレーションは「誰も本気で見ない通知」を上へ運ぶ装置になります。モニター側でアラート疲れを減らす手立てはそちらの解説にあるので、On-Call 側では「high に繋ぐのは人が今すぐ動く必要があるものだけ」という 1 行の規則を先に置いてください。3 つの問いに答えられたら、ルーティングルールは後回しで構いません。1 チーム、1 スケジュール、2 段のポリシー、high だけをページに繋ぐ最小構成で 1 ヶ月回し、確認までの時間と上がった回数を見てから広げるのが、当番表が長続きする順序です。