ガイド

著者 Matt Connor 2026-07-15 ・更新日 2026-07-24

Uptime KumaをDockerで構築！監視サーバーの最適な構成

Q: Telegram やメールでアラートを受け取るにはどうすればよいですか？

Settings > Notifications からチャンネルを追加し、各 monitor に紐付けてください。Telegram の場合は、@BotFather で bot を作成し、https://api.telegram.org/bot /getUpdates から chat.id を取得してください。メールの場合は、SSL には 465 を、STARTTLS には 587 を使用してください。プロバイダーが 2FA を使用している場合は、app password が必要です。Test を押し、メッセージが届くことを確認してから運用を開始してください。

Q: Uptime Kuma で cron ジョブやバックアップスクリプトを監視できますか？

はい、Push monitor を使用してください。Uptime Kuma が URL を発行します。スクリプトの最後に curl を実行することで、成功したときのみ通知を飛ばせます。ジョブが失敗するかサーバーがダウンすると、heartbeat が届かなくなるため、設定したインターバル経過後にアラートが送信されます。外部からのチェックでは内部の状態を把握できないため、これがスケジュールジョブの実行を確認する唯一の確実な方法です。

Uptime KumaをDockerで構築して、WebサイトやDNSを監視しましょう。監視対象と同じサーバーで実行すると誤検知の原因になるため、別のVPSで運用するのが鉄則です。メモリ256MBから動作する軽量な構成で、TelegramやDiscordへの通知、公開ステータスページの作成方法を解説します。

作成するもの

外部から他のサーバーやウェブサイトを監視する、軽量な単一コンテナです。対象が応答を停止した際、email、Telegram、Discord、または webhook を通じて即座に通知します。 Uptime Kuma は SQLite ファイルをバックエンドに持つ単一の Node プロセスです。そのため、256-512 MB の RAM で十分に動作します。また、ライブダッシュボード、履歴グラフ、公開ステータスページを提供します。インストールは 10 行程度の Compose ファイルで完了します。重要なのは、どこで実行するか、そして テスト時にアラートが正しく送信されるか です。通知が届くことが確認できていない監視ツールは、全くない場合よりも危険です。何も監視できていないのに、保護されているという誤った安心感を与えてしまうからです。

障害の影響を受けない場所で monitor を実行する

この決定が全体の成否を分けるため、最初に行う必要があります。Uptime Kuma を監視対象と同じサーバーで実行しないでください。 監視対象のサーバー自体がダウンしたり、メモリ不足になったりした場合、monitor も同時に停止します。その結果、アラートが送信されず、monitor が停止している状態は「すべて正常」である状態と同じに見えてしまいます。また、サーバーが稼働している場合でも注意が必要です。localhost を監視する場合、monitor はワークロードと CPU を共有します。そのため、負荷が急増すると check がタイムアウトし、実際のサービスは正常であるにもかかわらず、対象が down と判定される誤検知が発生します。

したがって、Uptime Kuma は監視対象とは別の VPS で実行してください。理想的には、ユーザーと同じ経路（パブリックインターネット経由の hostname）でサービスに到達できる、別のプロバイダーやリージョンが望ましいです。安価なインスタンスで十分であり、1台の小さな monitoring VPS ですべてのサーバーを監視できます。Kuma 自体の停止を検知するために、別の場所から cron を使用して push heartbeat を追加してください。

前提条件とリソース要件

新規にインストールされた Ubuntu 24.04 VPS。Docker Engine と Compose v2 plugin が必要です。これらは、更新が遅れる docker.io ディストリビューションのパッケージではなく、Docker 公式の apt リポジトリからインストールしてください。
256 MB RAM であれば数個のモニターを運用可能です。数十個のモニターと reverse proxy を快適に動作させるには、512 MB から 1 GB の RAM を推奨します。チェック実行時以外、CPU 使用率はほぼアイドル状態になります。
ドメインと DNS A レコード（例：VPS を指す status.example.com）。TLS と公開ステータスページが必要な場合のみ必要です。プライベート環境であれば、DNS は不要で、VPN や SSH tunnel が利用可能です。
アラート送信先へのアウトバウンドネットワーク接続。SMTP（メールプロバイダー宛）または HTTPS（Telegram や Discord 宛）。

Compose file

これを /srv/uptime-kuma/compose.yaml に配置してください。

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data

volumes:
  kuma-data:

起動して、初回起動時のログを確認します。

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

正常に起動すると、Listening on 3001 が出力され、その後ログは止まります。このファイルには意図的な設定が3つあります。

3001:3001 ではなく 127.0.0.1:3001:3001 です。 Docker は ufw がパケットを検知する前に DNAT ルールでポートを公開します。そのため、3001:3001 をそのまま設定すると、ファイアウォールの設定に関わらずダッシュボードがパブリックインターネットに公開されます。ループバックにバインドすることで、リバースプロキシのみを公開し、プライベートな状態を維持できます。プライベートなインスタンスの場合、プロキシを介さずセルフホストの WireGuard VPN 経由で 3001 にアクセスすることも可能です。

/app/data に名前付きボリュームを使用しています。 Uptime Kuma が保持するすべてのデータ（SQLite データベース、モニター、通知設定、ステータスページのロゴ）はここに保存されます。これを失うと、管理画面は初期状態に戻ります。バックアップが必要な唯一の項目です。

イメージのタグを主要バージョン :2 に固定しています。 これは現在の安定版ラインです。コピーする前に、Docker Hub で最新の主要バージョンを確認してください。プロジェクトが非推奨としている latest のような、更新され続けるタグ（moving tag）は使用しないでください。このイメージのメジャーバージョンアップは、一方通行のデータベース移行を伴います。ルーチン的な pull で意図せず発生させるべきではありません。

注意点：/app/data は POSIX ファイルロックをサポートするファイルシステム上に配置する必要があります。ローカルの Docker volume であれば問題ありません。NFS 上では SQLite データベースが破損し、SQLITE_BUSY および database disk image is malformed が発生するため、ネットワーク共有は絶対に使用しないでください。

初回実行: admin アカウントの作成

https://status.example.com のプロキシ経由、または SSH tunnel を使用してインスタンスにアクセスしてください。ssh -L 3001:127.0.0.1:3001 user@your-vps を実行し、http://localhost:3001 を開きます。最初のページには、管理者ユーザー名とパスワードを設定するフォームが表示されます。デフォルトのログイン情報は存在しません。強力なパスワードを設定してください。このダッシュボードは、監視対象のすべての内部アドレスとトークンにアクセスします。パスワードを忘れた場合は、ブラウザからではなく、ホストからリセットしてください。

sudo docker compose exec uptime-kuma npm run reset-password

最初に通知チャネルを追加し、テストを行ってください

モニターを追加する前にアラートを設定してください。これにより、モニター作成時にチャネルを紐付けることができます。Settings > Notifications > Setup Notification に移動してください。各チャネルの Test ボタンを使用し、メッセージが届くことを確認してください。テストされていない通知は、設定がサイレントに失敗する原因として2番目に多いものです。

Email (SMTP). host、port、encryption、username、password、From、To を入力してください。動作する組み合わせは、465 で "Secure" を TLS/SSL に設定するか、587 で STARTTLS を使用する場合の2通りです。Gmailや2要素認証を使用しているプロバイダーでは、app password を生成する必要があります。通常のパスワードを使用すると Error: Invalid login: 535-5.7.8 Username and Password not accepted が返されます。

Telegram. @BotFather に /newbot と送信し、bot token をコピーしてください。chat ID を取得するには、新しい bot に一度メッセージを送信し、https://api.telegram.org/bot<token>/getUpdates を開いて JSON から chat.id を読み取ってください。一度もメッセージを送信していない bot は getUpdates が空のため、送信先がありません。

Discord. 対象のチャネルで Edit Channel > Integrations > Webhooks > New Webhook を開き、URL をコピーして Discord 通知として貼り付けてください。

Generic webhook. Slack の incoming webhook、カスタムエンドポイント、ホームオートメーション用フックなど、その他のサービスに使用します。Webhook タイプは、指定した URL に JSON ペイロードを POST します。また、組み込まれている Apprise 統合により、リストにある他の90以上のサービスの多くをカバーしています。

モニターを1つずつ追加する

Add New Monitor をクリックし、タイプを選択します。Friendly Name、Check Interval（60 seconds が推奨）、Retries（「down」と判定されるまでの連続失敗回数。パケットの欠落による誤検知を防ぐため 2 または 3 を推奨）、および通知設定を設定してください。使用するタイプは以下の通りです。

HTTP(s). 完全な URL を指定します。ステータスコードが受理されていれば「up」と判定されます（デフォルトは 200-299 です。301 や 401 が正常な場合は、Accepted Status Codes で範囲を広げてください）。Webサイトや API の監視に最適です。
HTTP(s) - Keyword. HTTP(s) と同じリクエストを行い、ボディ内に特定の文字列が含まれていること（または Invert がオフであること）を確認します。これにより、HTTP ステータスは正常でも、ボディに "Error establishing a database connection" と表示されている 200 OK のような状態を検知できます。
TCP Port. ホストとポートへの TCP 接続を確認します。HTTP 以外のサービス（22 番の SSH、5432 番の Postgres、25 番の SMTP サーバー、ゲームサーバーなど）に使用します。
Ping. ICMP echo を使用します。疎通確認とレイテンシの測定に適しています。ただし、多くのネットワークやクラウドのファイアウォールは ICMP を破棄するため、Ping の失敗が「ホストの停止」ではなく「プロバイダーによる ICMP ブロック」である可能性があります。TCP モニターで併用して確認してください。
DNS. 指定したリゾルバーに対してレコード（A, AAAA, MX, TXT など）の解決を行い、その結果を検証します。レジストラや DNS の障害を早期に検知できます。
Push. 次のセクションで説明する、内部から外部へ通知する形式のモニターです。

Push (heartbeat) モニターによる cron job の監視

上記のモニターはすべて、外部からサービスへアクセスします。Push モニターは逆の仕組みで動作します。Uptime Kuma が待機し、ジョブ側から「実行完了」を通知します。バックアップや cron を監視する場合、これが唯一の確実な方法です。HTTP チェックでは URL の応答は確認できますが、ジョブが正常に完了したかどうかはジョブ自身にしか分からないためです。

モニターのタイプを Push に設定してください。Uptime Kuma は次のような一意の URL を生成します：

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

Heartbeat Interval には、ジョブの実行間隔に少しの猶予を加えた時間を設定します。次に、スクリプトの末尾に以下の行を追加し、成功時のみ通知が送信されるようにします：

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

ジョブが失敗した場合、set -e は curl を実行する前に中断されます。サーバーがダウンしている場合も、実行されません。いずれの場合も heartbeat が停止します。インターバルにリトライ回数を加えた期間が経過すると、Uptime Kuma はモニターの状態を down に変更し、アラートを送信します。この push token は機密情報として扱ってください。これを知っている人は誰でも、正常な heartbeat を偽装できます。

公開ステータスページの作成

ステータスページは、ダッシュボードを公開せずに、サービスの稼働状況や履歴を顧客に提示するためのものです。Status Pages から New Status Page を選択してください。名前と slug（/status/main のような公開パス）を入力します。表示したい monitor を "Websites" や "APIs" といった group にドラッグして追加します。logo と短い description を追加し、Save をクリックしてください。また、ページを独自の domain に紐付けて、status.example.com から直接配信することも可能です。

注意点が2つあります。ステータスページはサービスの存在と稼働状況を公開するため、公開してもよい monitor のみを追加してください。また、ダッシュボードはログインが必要ですが、ステータスページは意図的に公開設定となっており、認証は不要です。

TLSを備えたリバースプロキシの構成とWebSocketsへの注意

パブリックインスタンスの場合、TLSとホスト名を使用するために、loopbackにバインドされたコンテナの前にリバースプロキシを配置してください。注意すべき重要な点は、Uptime KumaのUIはSocket.IOを使用したライブアプリであるため、プロキシでWebSocket接続のUpgradeを許可する必要があることです。これを忘れると、ページは読み込まれるものの接続は確立されません。ダッシュボードは「Connecting...」のまま更新されず、ブラウザのコンソールには WebSocket connection to 'wss://.../socket.io/...' failed と表示されます。

nginxとcertbotをインストールし、loopbackポートへプロキシするvhostを作成してください。まずはport 80で設定し、後からcertbotでTLSを追加してください。証明書の発行、更新タイマー、および失敗時の挙動については、issuing Let's Encrypt certificates with certbot and nginx で説明しています。

sudo apt install -y nginx certbot python3-certbot-nginx

これを /etc/nginx/sites-available/status.example.com として保存してください。重要なのは以下の2行のWebSocket設定です。

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

サイトを有効化して設定をテストした後、certbotを使用して443ポートで待機するようにブロックを書き換え、証明書を適用し、HTTPからHTTPSへのリダイレクトを追加してください。

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

Upgrade と Connection "upgrade" のペアが最も重要です。また、proxy_read_timeout 3600s はnginxが長時間維持されるソケットを切断するのを防ぎます。certbotはこれら両方を生成された443ブロック内にコピーします。すでに1つのプロキシで複数のコンテナを運用している場合は、routing them through Traefik with automatic TLS を使用してください。コンテナラベルを使用して同様の構成ができ、デフォルトでWebSocketのUpgradeを転送します。

vhost全体にbasic-authを適用しないでください。そうすると、パブリックステータスページと /api/push エンドポイントへのアクセスも遮断されます。Uptime Kuma内蔵のログイン機能を使用し、インターネット公開する場合は fail2ban watching for repeated failed logins を追加してください。ダッシュボードを公開する必要がない場合は、プロキシを使用せずVPN経由でアクセスしてください。

正しい証明書の有効期限監視

HTTP(s) モニターを使用すると、TLS 証明書の期限切れ前に警告を受け取れます。Certificate Expiry Notification にチェックを入れると、Uptime Kuma は指定した日数前にアラートを送信します。設定を誤ると正しく動作しません。

IP ではなく hostname で監視してください。SNI なしのリクエストはサーバーのデフォルト証明書を取得するため、Hostname/IP does not match certificate's altnames が表示されます。

また、有効期限の警告が必要なモニターでは Ignore TLS/SSL Error を有効にしないでください。この設定は自己署名証明書を使用する内部ホスト（unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT）用です。これを有効にすると、Uptime Kuma は証明書の有効期限を含め、証明書自体のチェックを停止します。

Backups: 1つのディレクトリで完結します

すべてのデータは /app/data に保存されます。コンテナを停止した状態でボリュームのコピーを作成することで、SQLiteファイルの整合性を保ったバックアップが可能です。

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

Composeはボリューム名にプロジェクトディレクトリ名を接頭辞として付与するため、まず docker volume ls | grep kuma でボリュームの正確な名前を確認してください。次に、作成したtarballをサーバーの外へコピーしてください。同じVPS内に保存したものはバックアップとは呼べません。リストアは、スタックを停止し、空の /app/data ボリュームに展開してから、スタックを起動するという手順で行います。

Upgrades

アップグレードは、イメージの pull によって行われます。

cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

新しいコンテナは、初回起動時にデータベースの migration を実行します。docker compose logs -f を確認してください。pull を行う前に、上記のバックアップを取得してください。また、major tag の範囲内で更新してください。:1 から :2 への移行は、一方通行の migration です。必ず事前にバックアップを取り、release notes を確認してください。

発生するエラーと表示される文字列

localhostを監視している場合の、誤った「down」判定。 モニターが timeout of 48000ms exceeded または connect ETIMEDOUT で赤くなりますが、実際にはノートPCからサービスへ応答があります。Uptime Kumaと同じホストを監視対象にしている場合、ターゲットではなく、CPUやメモリのスパイクがチェックを阻害しています。モニターを別のVPSに移動し、パブリックなhostnameをターゲットにしてください。

connect ECONNREFUSED 127.0.0.1:443 (または任意のport)。そのportで何もListenしていません。サービスが停止しているか、コンテナ内部から localhost を監視しています。その場合、127.0.0.1 はサーバーではなくコンテナです。loopbackではなく、パブリックなhostnameを監視してください。

メールテストでの Invalid login: 535-5.7.8 Username and Password not accepted。SMTPの認証情報が間違っています。または、プロバイダーがapp-specific passwordを必要としているところに、アカウントのpasswordを入力しています。app passwordを生成して、それを貼り付けてください。

メールテストでの connect ETIMEDOUT または queryA ETIMEDOUT <host>。portが間違っているか、プロバイダーがアウトバウンドのSMTPをブロックしています。465 または 587 がSecure/STARTTLSの設定と一致しているか確認してください。また、nc -vz smtp.example.com 587 を使用してホストからテストを行ってください。多くのプロバイダーはアウトバウンドの 25 をブロックしており、一部のプロバイダーはリクエストがあるまでsubmission portをブロックします。

メールテストでの self signed certificate または unable to verify the first certificate。SMTPサーバーがNodeが信頼できないcertificateを提示しています。問題を隠蔽するのではなく、メールサーバーのcertificateを修正してください。

Dashboardが「Connecting...」のまま止まり、consoleに WebSocket connection ... failed が表示される。 リバースプロキシがWebSocketをupgradeしていません。nginxに Upgrade と Connection "upgrade" のheaderを追加するか、TraefikやCaddyのようにデフォルトでこれらを転送するproxyを使用してください。HTMLのロードは通常のHTTP GETであるため成功しますが、ライブソケットにはupgradeが必要です。

証明書の期限切れモニターが警告を出さない、または誤った警告を出す。 Ignore TLS/SSL Error にチェックが入っており、証明書のチェックが無効化されているか、あるいはモニターがIPアドレスをターゲットにしており、SNIの欠如により誤ったcertificateを読み込んで Hostname/IP does not match certificate's altnames を表示しています。チェックを外し、hostnameで監視してください。

ログ内の SQLITE_BUSY または database disk image is malformed。/app/data volumeが、適切なfile lockingのないfilesystem（通常はNFS）にあります。これをローカルのDocker volumeに移動し、バックアップからリストアしてください。

FAQ

Uptime monitor の実行場所はどこが最適ですか？

監視対象とは別のサーバーで実行してください。理想的には、別のプロバイダーやリージョンを使用し、ユーザーと同じようにパブリックインターネット経由で hostname を使用してアクセスしてください。監視対象と同じサーバーで実行すると、サーバーがダウンした際に監視機能も停止します。また、ホストの負荷が高いと、正常なサービスに対しても「ダウン」と誤判定します。小さな別の VPS を使用することで、これら両方の問題を回避できます。

Telegram やメールでアラートを受け取るにはどうすればよいですか？

Settings > Notifications からチャンネルを追加し、各 monitor に紐付けてください。Telegram の場合は、@BotFather で bot を作成し、https://api.telegram.org/bot<token>/getUpdates から chat.id を取得してください。メールの場合は、SSL には 465 を、STARTTLS には 587 を使用してください。プロバイダーが 2FA を使用している場合は、app password が必要です。Test を押し、メッセージが届くことを確認してから運用を開始してください。

Uptime Kuma で cron ジョブやバックアップスクリプトを監視できますか？

はい、Push monitor を使用してください。Uptime Kuma が URL を発行します。スクリプトの最後に curl を実行することで、成功したときのみ通知を飛ばせます。ジョブが失敗するかサーバーがダウンすると、heartbeat が届かなくなるため、設定したインターバル経過後にアラートが送信されます。外部からのチェックでは内部の状態を把握できないため、これがスケジュールジョブの実行を確認する唯一の確実な方法です。

Uptime Kuma と Zabbix のどちらを導入すべきですか？

Uptime Kuma は、「外部から見て稼働しているか」「アラートが飛ぶか」という問いに対し、リソースをほとんど消費せずに 10 分で設定でき、ステータスページも提供します。CPU、メモリ、ディスクの推移や、広範囲な閾値設定などの詳細なメトリクス収集機能はありません。それらが必要な場合は、フル機能の Zabbix モニタリングサーバーが適しています。Zabbix はエージェントベースのより重いツールであるため、両方を併用するユーザーも多いです。導入に迷っている場合は、2026年にセルフホストすべきサービスまとめを参考にしてください。

#uptime-kuma#monitoring #docker #self-hosting#status-page