--- title: "Uptime Kumaで電話アラート：ダウン時にスマホを鳴らす方法" description: "Uptime Kumaには90以上の通知先がありますが、電話を鳴らすものはありません。Webhook 1本でダウン時の電話アラートを追加する方法を解説します。" date: 2026-08-28 author: Nooc authorAvatarLink: /images/avatars/nooc.webp authorLink: https://nooc.me tags: - Uptime Kuma - セルフホスト監視 - 電話アラート - Webhook通知 - 死活監視 - オンコール --- # Uptime Kumaで電話アラート：ダウン時にスマホを鳴らす方法 Uptime Kumaは90を超える通知プロバイダーに対応していますが、スマートフォンを鳴らせるものは1つもありません。監視対象がダウンしたときに電話を受け取るには、Uptime Kumaの **Webhook** 通知を、通知タイプを**通話**に設定したEchobellチャンネルへ送ります。この記事では、使うべきカスタムボディ、ダウン通知と復旧通知の分け方、そして設定を静かに壊す2つの落とし穴を扱います。 [Uptime Kuma](https://github.com/louislam/uptime-kuma)は、セルフホスト型の死活監視ツールとして最も普及しています。GitHubスター数はおよそ9万、2.5.0が2026年8月にリリースされました。HTTPエンドポイント、TCPポート、DNSレコード、Dockerコンテナなどを監視でき、ダウンの検知能力は本当に優秀です。 弱点はラストワンマイル、つまり眠っている人間にアラートを届ける部分にあります。 ## Uptime Kumaが単体で電話をかけられない理由 Uptime Kumaの通知先リストは長大です。Telegram、Discord、Slack、メール、Gotify、ntfyなど数十種類。しかしそのすべてが届けるのは**メッセージ**です。メッセージは着信音スイッチ、おやすみモード、iOSの集中モードの影響を受けます。午前3時にそれが意味するのは、アラートは届いたが何も起こらなかった、ということです。 「電話をかける」という公式プロバイダーは存在しません。多くの人が行き着く選択肢は次の3つです。 - **Twilio** — 音声通話を組むことは可能ですが、Uptime KumaのTwilioプロバイダーはSMSを送信します。通話にするにはブリッジサービスの実装、番号の購入、通話ごとの課金が必要です。 - **PagerDuty、Zenduty、Spike.sh、Splunk On-Call** — これらは実際に発信できますが、同時に本格的なインシデント管理プラットフォームであり、価格も席数課金です。ローテーションやエスカレーションポリシーが必要なら正解ですが、電話を鳴らしたいだけなら重すぎます。 - **SMSゲートウェイ** — SMSも結局メッセージです。iOSでは、送信者が許可リストに入っていない限り、テキストは集中モードを突破しません。 Uptime Kumaのリポジトリには[VoIP通話通知を求めるIssue](https://github.com/louislam/uptime-kuma/issues/3812)が長く開いたままです。それまでの抜け道が汎用の **Webhook** プロバイダーで、任意のURLに任意の内容をPOSTできます。必要なのはそれだけです。 ## 必要なもの - 稼働中のUptime Kumaインスタンス（本記事は2.x向け。カスタムボディは1.23+でも動作します） - Echobellのインストール（[App Store](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-uptime-kuma-phone-call-alerts-ja&mt=8) / [Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid)） - 5分 Uptime Kumaインスタンスから `hook.echobell.one` への外向きHTTPS通信が必要です。インターネットから到達可能である**必要はありません**。これは送信方向のWebhookなので、自宅サーバーやプライベートネットワーク内で動く監視でも問題なく機能します。 ## ステップ1 — 電話をかけるチャンネルを作る Echobellで `Production Down` のような名前のチャンネルを作成し、購読時の通知タイプを**通話**に設定します。ここが肝心です。通話タイプのアラートは着信画面として届き、iOSの集中モードやおやすみモードを貫いて鳴ります。プッシュ通知にはできないことです。 テンプレートは次のように設定します。 ``` タイトル: 🔴 {{monitor}} がダウンしました 本文: {{message}} 対象: {{target}} ``` そしてチャンネルの **Webhook URL** をコピーします。次のような形式です。 ``` https://hook.echobell.one/t/ ``` このURLは秘密情報として扱ってください。手に入れた人は誰でもあなたのスマートフォンを鳴らせます。 ## ステップ2 — EchobellをWebhook通知として追加する Uptime Kumaで **Settings → Notifications → Setup Notification** を開き、次のように入力します。 | 項目 | 値 | | --- | --- | | Notification Type | `Webhook` | | Friendly Name | `Echobell — Down` | | Post URL | EchobellのWebhook URL | | Request Body | `Custom Body` | **Additional Headers** は空のままにします。 ## ステップ3 — フィルタリングできるペイロードを送る 多くの解説が飛ばすステップであり、アラートシステムとノイズ製造機を分ける分岐点でもあります。 **Custom Body** に以下を貼り付けます。 ```json { "monitor": "{{name}}", "target": "{{hostnameOrURL}}", "message": "{{ msg | strip_newlines }}", "up": "{{ heartbeatJSON['status'] }}" } ``` Uptime KumaはカスタムボディをLiquidでレンダリングし、次の変数を提供します。 | 変数 | 内容 | | --- | --- | | `{{name}}` | 監視対象のフレンドリー名 | | `{{hostnameOrURL}}` | チェック対象のホスト名またはURL | | `{{status}}` | `🔴 Down`、`✅ Up`、`⚠️ Test` | | `{{msg}}` | 人が読める理由。例：`connect ECONNREFUSED 10.0.0.4:443` | | `{{ monitorJSON['...'] }}` | monitorオブジェクト全体 | | `{{ heartbeatJSON['...'] }}` | heartbeatオブジェクト全体 | このペイロードには意図的な点が2つあります。 **`msg` への `strip_newlines`。** Uptime Kumaのメッセージには改行が含まれることが多く、JSON文字列内の生の改行は不正なJSONです。このフィルターがないと、Webhookは断続的に失敗します。しかも失敗するのは、たまたま改行を含むエラーのときだけです。お使いのUptime KumaがLiquidの `json` フィルターに対応していれば、`"message": {{ msg | json }}`（前後の引用符は不要）がさらに安全です。引用符もエスケープしてくれます。 **`{{status}}` ではなく `heartbeatJSON['status']`。** `status` 変数は絵文字付きのテキストになるため、比較には扱いにくいものです。heartbeatのステータスは素の数値です。 - `0` — ダウン - `1` — 稼働中 - `2` — 保留 - `3` — メンテナンス 引用符で囲むこと（`"up": "{{ ... }}"`）も重要です。理由はステップ5で説明します。 ## ステップ4 — 復旧通知で電話がかかってこないようにする Uptime Kumaの1つの通知は、ダウン時**と**復旧時の両方で発火します。そのままにすると、サービスが壊れたときに電話がかかり、自然復旧したときにもう一度かかってきます。人々に1本目を無視することを教えてしまうのは、この2本目です。 Echobellの**条件**で分離します。条件は配信前に評価されます。 **`Production Down` チャンネル**（通知タイプ**通話**）の条件を次のように設定します。 ``` up == "0" ``` **2つ目のチャンネル**として `Production Recovered` を作成し、通知タイプを**通常**にして、条件を設定します。 ``` up == "1" ``` テンプレートは次のとおりです。 ``` タイトル: ✅ {{monitor}} が復旧しました 本文: {{message}} ``` そしてUptime Kumaに2つ目のWebhook通知を追加します。カスタムボディも監視対象も同じで、URLだけ復旧チャンネルのものにします。両方の通知がすべてのイベントを受け取り、各チャンネルが不要な半分を捨てます。 結果として、ダウンは鳴り、復旧は翌朝読む静かなプッシュになります。 ## ステップ5 — オオカミ少年にならないよう監視を調整する 2秒のネットワークの揺らぎのために鳴った電話は、電話がないことより悪い結果を招きます。次の1本も無視されるからです。監視対象側にあるUptime Kumaの3つの設定が、この問題の大半を解決します。 - **Retries** — `2` か `3` に設定します。Uptime Kumaはこの回数だけ連続で失敗して初めてダウンと判定するため、単発のパケットロスを除外できます。 - **Heartbeat Retry Interval** — 失敗中の再チェック間隔です。20〜30秒が妥当なバランスで、リトライ3回と組み合わせれば、実際の障害を約1分で検知できます。 - **Resend Notification if Down X times consecutively** — `10` 程度にしておくと、さらに10回チェックしてもダウンしたままの場合に再度電話がかかります。粗削りなエスカレーションポリシーですが、機能します。 未応答の通話を再送を待たずにすぐ再試行したい場合は、Echobellのアプリ設定で**失敗した通話を再試行**をオンにしてください。 ## 業務時間外だけ鳴らす 日中はおそらくすでにダッシュボードを見ているので、鳴る電話は不要な割り込みです。Echobellのシステム時刻変数（すべてUTC）を使えば、1つのチャンネルを時間帯によって別の挙動にできます。 ``` up == "0" && (hour >= 17 || hour < 9) ``` この条件では、UTCの09:00〜17:00の外側でのみ電話がかかります。日中用には、通知タイプが通常の2つ目のチャンネルに逆の条件を設定します。 ``` up == "0" && hour >= 9 && hour < 17 ``` 自分のタイムゾーンへの換算を忘れずに。これらの変数は常にUTCで計算されます。詳しくは[UTC条件による時間帯別通知](/ja/blog/time-window-notifications-using-utc-conditions)で解説しています。 ## チームでアラートを共有する Echobellのチャンネルは購読リンクでチームメンバーと共有でき、購読者それぞれが自分の通知タイプを選べます。つまり同じ監視対象が、オンコール担当のスマートフォンを鳴らしつつ、他のメンバーには通常のプッシュとして届きます。席数課金も、Uptime Kuma側の追加のルーティングルールも不要です。 これはセルフホストを選んだそもそもの理由であるプライバシー面とも相性が良い設計です。監視は自分のインフラに残り、Echobellは通知の内容と履歴をサーバーではなく端末側に保持します。 ## この構成で得られないもの 境界を正直に示しておくと、後々の不幸な移行を避けられます。Echobellは配信レイヤーであり、インシデント管理プラットフォームではありません。次の機能はありません。 - オンコールのローテーションスケジュールやフォロー・ザ・サンの引き継ぎ - 2人目を自動的に呼び出すエスカレーションツリー - インシデントのタイムライン、確認応答の追跡、ポストモーテム支援 これらが必要なチームには、PagerDutyやGrafana Cloud IRMなどが必要です。この構成が埋めるのは、Uptime Kumaが空けたままにしている具体的な穴、つまり検知した障害を実際に鳴るスマートフォンへ変換する部分です。個人運用者、小規模チーム、ホームラボにとっては、たいていこれが要件のすべてです。 ## トラブルシューティング **Testボタンを押しても何も起きない。** 上記のペイロードでは想定どおりの挙動で、誰もが最初は戸惑います。Testを押した時点でUptime Kumaにはレンダリングできるheartbeatがないため、`{{ heartbeatJSON['status'] }}` は空文字列になり、どちらの条件にも一致しません。きちんとテストするには、何も待ち受けていないポート（`127.0.0.1:9`）に向けた使い捨てのTCP監視を作り、実際に失敗させてください。 **Webhookが断続的に失敗する。** ほぼ確実に改行の問題です。`msg` が `strip_newlines` を通っているか確認してください。改行を含むエラーメッセージのときだけ壊れるため、ランダムに見えます。 **EchobellがHTTP 200で `success: false` を返す。** チャンネルトークンが誤っているか、チャンネルが削除されています。長さは正しいが存在しないトークンにもEchobellは `200` を返すため、ステータスコードではなくJSONボディを確認してください。 **HTTP 405。** チャンネルで **POST Only** が有効なのにGETが送られています。Uptime KumaはPOSTするので、これは通常ブラウザでURLを開いたことを意味します。 **通知は届くが鳴らない。** その購読の通知タイプが通話ではなく、通常またはタイムセンシティブになっています。通知タイプは購読者ごとの設定なので、鳴らない端末側で確認してください。 ## よくある質問 ### Uptime Kumaは単体で電話をかけられますか？ いいえ。Uptime Kumaには90以上の通知プロバイダーがありますが、すべてメッセージを配信するものです。電話をかけるには、Echobellのように発信できるサービスへWebhookを転送するか、有料のインシデント管理プラットフォームを使う必要があります。 ### ファイアウォール内のセルフホストUptime Kumaでも動きますか？ はい。このWebhookはUptime Kumaインスタンスからの送信方向のHTTPSリクエストなので、`hook.echobell.one` に到達できれば十分です。インスタンスにグローバルアドレスは不要です。 ### 電話はおやすみモードを突破しますか？ はい。Echobellの通話タイプの通知は着信として提示されるため、iOSの集中モードとおやすみモードを貫いて鳴ります。詳細と関連設定は[重要アラートのためにiOS集中モードを突破する方法](/ja/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)を参照してください。 ### 復旧時に電話がかかるのを止めるには？ 条件付きのチャンネルを2つ使います。通話チャンネルには `up == "0"`、通常優先度の復旧チャンネルには `up == "1"` を設定し、それぞれにWebhook通知を向けます。手順は上記のステップ4のとおりです。 ### 同じ監視対象で複数人に電話できますか？ はい。チャンネルをチームメンバーと共有すれば、購読者それぞれが自分の通知タイプを選べます。通話チャンネルを購読している全員に電話がかかります。 ## まとめ 構成はWebhook 1本、カスタムボディ1つ、条件2つだけです。既存のUptime Kumaの監視設定、リトライロジック、ステータスページはそのままに、「監視が気づいた」と「人間が気づいた」の間の隙間を埋められます。 [iPhone版Echobellをダウンロード](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-uptime-kuma-phone-call-alerts-ja&mt=8)、または[Google Playで入手](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid)して、まずは重要でない監視対象を1つつなぎ、わざと失敗させてみてください。頼りにする前に、経路を信頼できるようにしておきましょう。 --- ## 関連記事 - [Uptime Kuma連携ドキュメント](/ja/docs/developer/uptime-kuma) - [チャンネル条件リファレンス](/ja/docs/conditions) - [EchobellでUpptimeのアラートを受け取る](/ja/blog/upptime-alerts-with-echobell) - [APIダウン時の電話アラート](/ja/blog/phone-call-alerts-api-downtime) - [開発者のためのアラート疲れ解消ガイド](/ja/blog/fix-alert-fatigue-developer-guide)