Uptime Kumaで電話アラート：ダウン時にスマホを鳴らす方法

Uptime Kumaには90以上の通知先がありますが、電話を鳴らすものはありません。Webhook 1本でダウン時の電話アラートを追加する方法を解説します。

目次

Uptime Kumaは90を超える通知プロバイダーに対応していますが、スマートフォンを鳴らせるものは1つもありません。監視対象がダウンしたときに電話を受け取るには、Uptime Kumaの Webhook 通知を、通知タイプを通話に設定したEchobellチャンネルへ送ります。この記事では、使うべきカスタムボディ、ダウン通知と復旧通知の分け方、そして設定を静かに壊す2つの落とし穴を扱います。

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が長く開いたままです。それまでの抜け道が汎用の Webhook プロバイダーで、任意のURLに任意の内容をPOSTできます。必要なのはそれだけです。

必要なもの

  • 稼働中のUptime Kumaインスタンス（本記事は2.x向け。カスタムボディは1.23+でも動作します）
  • Echobellのインストール（App Store / Google Play）
  • 5分

Uptime Kumaインスタンスから hook.echobell.one への外向きHTTPS通信が必要です。インターネットから到達可能である必要はありません。これは送信方向のWebhookなので、自宅サーバーやプライベートネットワーク内で動く監視でも問題なく機能します。

ステップ1 — 電話をかけるチャンネルを作る

Echobellで Production Down のような名前のチャンネルを作成し、購読時の通知タイプを通話に設定します。ここが肝心です。通話タイプのアラートは着信画面として届き、iOSの集中モードやおやすみモードを貫いて鳴ります。プッシュ通知にはできないことです。

テンプレートは次のように設定します。

タイトル: 🔴 {{monitor}} がダウンしました
本文: {{message}}
対象: {{target}}

そしてチャンネルの Webhook URL をコピーします。次のような形式です。

https://hook.echobell.one/t/<channel-token>

このURLは秘密情報として扱ってください。手に入れた人は誰でもあなたのスマートフォンを鳴らせます。

ステップ2 — EchobellをWebhook通知として追加する

Uptime Kumaで Settings → Notifications → Setup Notification を開き、次のように入力します。

項目値
Notification TypeWebhook
Friendly NameEchobell — Down
Post URLEchobellのWebhook URL
Request BodyCustom Body

Additional Headers は空のままにします。

ステップ3 — フィルタリングできるペイロードを送る

多くの解説が飛ばすステップであり、アラートシステムとノイズ製造機を分ける分岐点でもあります。

Custom Body に以下を貼り付けます。

{
  "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条件による時間帯別通知で解説しています。

チームでアラートを共有する

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集中モードを突破する方法を参照してください。

復旧時に電話がかかるのを止めるには？

条件付きのチャンネルを2つ使います。通話チャンネルには up == "0"、通常優先度の復旧チャンネルには up == "1" を設定し、それぞれにWebhook通知を向けます。手順は上記のステップ4のとおりです。

同じ監視対象で複数人に電話できますか？

はい。チャンネルをチームメンバーと共有すれば、購読者それぞれが自分の通知タイプを選べます。通話チャンネルを購読している全員に電話がかかります。

まとめ

構成はWebhook 1本、カスタムボディ1つ、条件2つだけです。既存のUptime Kumaの監視設定、リトライロジック、ステータスページはそのままに、「監視が気づいた」と「人間が気づいた」の間の隙間を埋められます。

iPhone版Echobellをダウンロード、またはGoogle Playで入手して、まずは重要でない監視対象を1つつなぎ、わざと失敗させてみてください。頼りにする前に、経路を信頼できるようにしておきましょう。

関連記事

関連記事

CRAの24時間タイマーは2026年9月11日に始まる：誰かが必ず出られる体制を

2026年9月11日から、EUサイバーレジリエンス法は製造者に24時間以内の早期警告提出を義務づけます。提出はブラウザ経由のみでAPIはありません。そのトリガーをEchobellで電話に変える方法と、それでも解決できないことを解説します。

続きを読む

DORA と NIS2 のインシデント報告：タイムリミットが切れる前に電話を受け取る

DORA は分類から 4 時間、NIS2 は認知から 24 時間。どちらの時計も夜間に止まりません。検知アラートを Echobell で本当に鳴る電話に変える方法を解説します。

続きを読む

Cronジョブ失敗アラート：定期ジョブが止まったら電話を鳴らす

Cronジョブは静かに失敗します。失敗や実行漏れを検知し、数秒以内にプッシュ通知や電話アラートを受け取る3つの確実なパターンを解説します。

続きを読む