Uptime Kumaの使い方：無料で死活監視を始める手順【2026年版】

「サイトが落ちていたのに、半日たってから気づいた」——個人でサイトや VPS を運営していると、一度は経験するトラブルです。Uptime Kuma（アップタイム・クマ） は、こうした停止をすぐに知らせてくれる 無料のセルフホスト型の監視ツール です。

GitHub – louislam/uptime-kuma: A fancy self-hosted monitoring tool

この記事では、Uptime Kuma の使い方を Docker での構築 → HTTP 監視 → DNS 監視 → Discord 通知 → ステータスページ の順に、最新版（2026年11月時点で 2.5.11）の公式情報にもとづいて解説します。後半には、テスト用の Linux 環境（Docker）で実際にセットアップしたときの画面も載せています。UptimeRobot などの監視サービスとの違いや、更新・バックアップの注意点も整理しているので、「自分で監視を始めるための一冊目の手順書」 という位置づけで読んでください。

Uptime Kumaとは？一言でまとめると

一言でまとめると、Uptime Kuma は 「自分のサーバーに置く、無料で見た目の分かりやすい死活監視ツール」 です。死活監視とは、サイトやサーバーが動いているかを決まった間隔で確かめ、止まったら知らせる仕組みのことです。

UptimeRobot のような監視サービスは、他社のサーバーから自分のサイトを見てくれます。Uptime Kuma は逆に、監視の仕組みそのものを自分で立てる タイプです。ソフトはオープンソース（MIT ライセンス）で、使用料はかかりません。

※ 出典: Uptime Kuma 公式 GitHub・リリースページ。

v2（2.0.0 以降）では、データベースに SQLite のほか MariaDB も選べる ようになりました。ネットで見つかる古い解説は v1 のままのことが多いので、タグとデータベースの選び方は v2 の前提で読み替える のがポイントです。

UptimeRobotとの違いは？監視サービスとの比較と選び方

迷いやすいのが、監視サービスの UptimeRobot との使い分けです。大きな違いは 「置き場所を自分で用意するかどうか」 です。

※ 料金は米ドル。2026年11月13日時点の公式ページの表示。UptimeRobot には30秒間隔の Team（月46ドル、年払いは月39ドル）もあります。

IT Picks の見方としては、監視用に別のサーバーを用意できるなら Uptime Kuma、まだ用意できないなら UptimeRobot の無料プランから が始めやすいと考えています。どちらか一方に決める必要はなく、Uptime Kuma 自体が止まっていないかを監視サービスで見張る 併用もおすすめです。

始める前の準備：置き場所の選び方と必要なもの

Uptime Kuma を始める前に、どこで動かすか を決めます。ここを間違えると、いざというときに通知が来ません。

① 監視したいサーバーとは別の場所に置く

いちばん大事なのは、監視する側と監視される側を分ける ことです。同じ VPS に置くと、VPS ごと止まったときに Uptime Kuma も止まり、「止まった」という通知そのものが届きません。

監視用には、本番とは別の小さな VPS や、常に電源が入っている自宅の Linux マシンなどが候補になります。VPS の選び方は次の記事で比較しています。

あわせて読みたい

【2026年版】VPSおすすめの選び方｜失敗しやすいポイントと候補まとめ

② 動かせる環境を確かめる

公式が対応しているのは、Debian・Ubuntu・Fedora などの主要な Linux と、Windows 10（x64）・Windows Server 2012 R2 以降です。FreeBSD などは対象外です。

もう1つの注意は保存先です。公式は NFS などのネットワーク上のファイルシステムに /app/data を置かない ように案内しています。SQLite のファイルが壊れるおそれがあるためで、ローカルのディレクトリか Docker のボリューム を使います。

※ イメージのサイズは Docker Hub の表示（2026年11月13日時点）。

Dockerでの構築手順：起動から管理者の作成まで

ここからは、Uptime Kuma を Docker で立てる手順です。全体の流れは次のとおりです。

① docker run で起動する

いちばん手早いのは docker run です。公式の手順のコマンドに、ポートを自分のマシンの中だけに限る 指定（127.0.0.1:）を足した形がおすすめです。

docker run -d --restart=unless-stopped \
  -p 127.0.0.1:3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:2

-p 3001:3001 のままだと、管理画面がインターネットに直接出ます。外から見たい場合は、後で説明する リバースプロキシ（HTTPS で中継するサーバー）経由 にするのが安心です。

② Docker Compose で起動する

設定をファイルで残したいなら Compose です。公式の compose.yaml は次の内容です（ポートだけ 127.0.0.1 に限る形に変えています）。

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

docker compose up -d

タグは 2（v2 の最新版） を使います。latest は v1 を指したままの古いタグ なので、今から始めるなら使いません。軽くしたいときの 2-slim は、組み込みの MariaDB と Chromium が入っていない版です。

※ 出典: Uptime Kuma 公式 Wiki「Docker Tags」（2026年11月13日時点）。

③ 最初の画面でデータベースを選ぶ

ブラウザで http://localhost:3001（サーバー上なら SSH のポート転送などで開きます）を開くと、「どのデータベースを使いたいですか？」 と聞かれます。選べるのは3つです。

個人で始めるなら SQLite で十分 です。なお公式は SQLite から MariaDB への移行を公式にはサポートしていない ため、監視を大量に増やす予定があるなら最初に決めておくと後悔しません。

④ 管理者アカウントを作る

次に 「Adminアカウントの作成」 でユーザー名とパスワードを決めます。これは Uptime Kuma の中だけで使うユーザーで、外部サービスへの登録はいりません。作成するとダッシュボードが開き、画面は最初から日本語で表示されます。監視の追加からステータスページまで、実際に動かした画面は下の「実際にセットアップしてみた」にまとめています。

HTTP監視の設定方法：サイトが動いているかを確かめる

最初に作るのは、Web サイトや API が応答するかを見る HTTP(s) 監視 です。ダッシュボードの 「監視の追加」 から設定します。

1. 監視タイプ で「HTTP(s)」を選ぶ
2. モニター表示名 に分かりやすい名前を入れる
3. URL に監視したいページの URL を入れる
4. 監視間隔 と 再試行回数 を決めて「保存」

迷いやすいのは間隔と再試行回数です。主な項目をまとめます。

ページの中に特定の文字があるかまで見たいときは、監視タイプを 「HTTP(s) – キーワード」 にします。「表示はされるが中身がエラー画面」という壊れ方にも気づけます。

DNS監視の設定方法：名前解決の異常に気づく

DNS 監視 は、ドメイン名から IP アドレスを正しく引けるかを確かめる監視です。サーバーは動いているのに DNS の設定ミスやドメインの期限切れでサイトが見られない ——という事故に気づけます。

設定する項目は次の4つです。

• ホスト名: 調べたいドメイン名（例: www.example.com）
• リゾルバサーバー: 問い合わせ先の DNS サーバー。既定は Cloudflare の 1.1.1.1
• ポート: 既定は 53
• DNSレコード設定: 調べるレコードの種類。既定は A（IPv4 アドレス）

結果の画面には 「Records: 〜」 と、実際に返ってきた値が表示されます。サーバーの引っ越しで IP アドレスを変えたときに、新しい値が返っているかを確かめる用途 にも使えます。ドメインの有効期限を知らせる「Domain Name Expiry Notification」もこの画面でオンにできます。

Discord通知の設定手順：止まったらスマホに届くようにする

監視は、止まったときに知らせてくれて初めて役に立ちます。ここでは、多くの人が使っている Discord への通知を設定します。Discord 側で Webhook（外からメッセージを送り込むための URL） を作り、それを Uptime Kuma に貼る流れです。

① Discord で Webhook の URL を作る

1. 通知を流したい、自分が管理する Discord サーバー の「サーバー設定」を開く
2. 「連携サービス」 を開き、「ウェブフックを作成」 を押す
3. 名前と、通知を流す テキストチャンネル を決める
4. 「ウェブフックURLをコピー」 で URL をコピーする

Uptime Kuma の画面の説明文には「ウェブフックを確認 -> 新しいウェブフック」と少し古い言い方が出ます。2026年11月時点の Discord のヘルプでは 「ウェブフックを作成」 なので、ボタンの名前が違っても慌てなくて大丈夫です。

Webhook の URL を知っている人は誰でもそのチャンネルに投稿できてしまうので、URL は人に見せない・公開のリポジトリに書かない ようにしてください。

② Uptime Kuma に貼り付ける

1. 右上のメニューから 設定 →「通知」→「通知設定」 を開く
2. 通知タイプ で「Discord」を選ぶ
3. 「Discord ウェブフック URL」 にコピーした URL を貼る
4. 必要なら BOTの表示名・メッセージの先頭に送信する文章（@everyone などのメンション）を入れる
5. 「テスト」 を押して、Discord にテストのメッセージが届くか確かめてから「保存」

主な項目は次のとおりです。

最後に、各監視の編集画面の右側 「通知」 で、作った Discord 通知にチェックが入っているかを確かめます。ここが外れていると、監視していても通知は飛びません。

ステータスページの作り方：稼働状況を公開する

ステータスページ は、サービスの稼働状況を利用者に見せるための公開ページです。障害のときに「今どうなっているか」を問い合わせなしで伝えられます。

1. 上のメニューの 「ステータスページ」→「新しいステータスページを追加」
2. 名前 と スラッグ（URL の一部。/status/<スラッグ> になる。英小文字・数字・ハイフン）を決めて「次へ」
3. 編集画面の 「監視の追加」 で、公開したい監視を選ぶ（「グループの追加」 で分類も可能）
4. 左側でタイトル・メモ・フッター・テーマなどを整えて 「保存」

編集画面には、障害のお知らせを出す 「インシデントを作成」 もあります。左側の 「ドメイン名」 に独自ドメインを入れると、status.example.com のような専用の URL で公開できます（DNS の設定などは別に必要です）。

ステータスページは ログインしていない人にも見える ページです。社内のサーバー名など、見せたくない名前の監視は載せない ようにしましょう。

実際にセットアップしてみた

2026年11月13日に、テスト用の Linux 環境（Docker）で次の手順を実際に動かしました。使ったのは公式イメージ louislam/uptime-kuma:2（画面のバージョン表示は 2.5.11）です。監視先には、同じ環境の中に立てたテスト用の Web サーバー（nginx のコンテナ ukt-web）と DNS サーバー（CoreDNS のコンテナ ukt-dns。www.example.test に 10.10.0.80 を返す設定）を使い、3つのコンテナを Docker のネットワーク ukt でつないでいます。

① docker run で起動する

docker run -d --restart=unless-stopped --network ukt -p 127.0.0.1:3001:3001 -v ukt-data:/app/data --name uptime-kuma louislam/uptime-kuma:2

db-config.json is not found
Starting Setup Database
Waiting for user action...

上の手順①のコマンドに、テスト用のネットワーク（--network ukt）を足しただけの形です。ログが「Waiting for user action…」で止まり、ブラウザで http://127.0.0.1:3001 を開くとデータベースの選択画面（/setup-database）に移りました。

② データベースを選び、管理者を作る

画面は最初から日本語でした。SQLite を選んで「次へ」を押すと、すぐに「Adminアカウントの作成」に進みます。

ユーザー名とパスワードを入れて「作成」を押すと、「監視がありません」と表示されたダッシュボードが開きました。

③ HTTP 監視を追加する

「監視の追加」で監視タイプ HTTP(s)、URL http://ukt-web/、監視間隔 20、再試行回数 1 にして保存しました。

既定の監視間隔は60秒・再試行回数は0で、間隔を20秒にするとリクエストタイムアウトが自動で16秒に変わりました。保存の直後に「正常 200 – OK」（応答 3ms）と表示されています。

④ サイトを止めて、異常になるか試す

テスト用の Web サーバーを止め、しばらくしてから起動し直しました。

docker stop ukt-web
docker start ukt-web

止めた直後の確認は黄色（再試行中）になり、止めてから約27秒後に「異常 connect EHOSTUNREACH 172.18.0.2:80」 に変わりました。再試行回数を1にしているので、1回目の失敗ではすぐに異常にならず、2回目で確定します。起動し直すと、次の確認で「正常 200 – OK」に戻りました。

⑤ DNS 監視を追加する

監視タイプ DNS で、ホスト名 www.example.test、リゾルバサーバーにテスト用の DNS サーバー（172.18.0.3）、ポート 53 を指定しました。

リゾルバの既定は 1.1.1.1、レコードの種類の既定は A です。結果には設定どおりの「Records: 10.10.0.80」が表示されました。

⑥ ステータスページを作る

「新しいステータスページを追加」で名前とスラッグ（test）を決め、編集画面の「監視の追加」で2つの監視を載せて保存しました。ログインしていないブラウザで /status/test を開いたのが次の画面です。

「すべてのサービスが稼働中」の表示と、④で止めたときの赤・黄色が残った稼働率（62.5%）がそのまま公開されています。更新間隔の既定は300秒で、「04:55後に再読み込みします」と表示されていました。

⑦ 使ったメモリを見て、片付ける

docker stats --no-stream
docker rm -f uptime-kuma ukt-web ukt-dns
docker volume rm ukt-data
docker network rm ukt

監視2件・起動から約5分の時点で、uptime-kuma のメモリ使用量は 137.4MiB でした。docker system df -v では、イメージ louislam/uptime-kuma:2 が 2.54GB（展開後）、データのボリュームは 1.953MB です。小さな構成での一時点の値なので、監視を増やした場合の目安ではありません。

この先は公式の手順

Discord 通知は、設定画面で通知タイプに Discord を選び、入力項目を確かめるところまでです。Webhook は作っていないので、通知が届く様子は確かめていません。通知タイプの一覧には100を超える項目が並んでいました。

Discord の Webhook の作成と「テスト」での送信は上の「Discord通知の設定手順」、リバースプロキシでの公開や更新は下の「運用のチェックリスト」で、公式の手順として説明しています。外部のサイトの監視もしていません。

運用のチェックリスト：更新・バックアップ・セキュリティ

Uptime Kuma は自分で管理するツールなので、立てた後の手入れ が欠かせません。最低限やっておきたいことをまとめます。

① 更新の手順

公式の手順は、新しいイメージを取ってきて、コンテナを作り直す方法です。データはボリュームに残るので消えません。

docker pull louislam/uptime-kuma:2
docker stop uptime-kuma
docker rm uptime-kuma
docker run -d --restart=unless-stopped \
  -p 127.0.0.1:3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:2

Compose で動かしている場合は、次の2行で同じことができます。

docker compose pull
docker compose up -d

② v1 から v2 に上げるときの注意

古い v1 を使っている人は、v2 への更新に破壊的な変更が含まれる 点に注意してください。記録の集計し直しが走り、公式の例では 監視20件・90日分で約7分、遅い環境では数時間かかることがあります。途中で止めないこと、そして 先に data ディレクトリをバックアップしておくこと が公式の強い注意です。v1 にあった JSON でのバックアップ・復元機能は v2 で削除されています。

③ リバースプロキシで公開するとき

Uptime Kuma の画面は WebSocket という常時接続の仕組みを使います。Nginx などで中継するときは、Upgrade と Connection のヘッダーを通す設定が必要です。公式 Wiki には Nginx・Apache・Caddy・Cloudflare Tunnel・Traefik の例があります。中継を使う場合は、設定の 「リバースプロキシ」 で Trust Proxy をオンにすると、ログに本当の接続元 IP が残ります。

VPS 自体の守り方は、次の記事も参考にしてください。

あわせて読みたい

XServer VPSのセキュリティ対策：最初にやる6つの設定【2026年版】

よくある質問

Q. Uptime Kuma は本当に無料ですか？ A. ソフト自体は MIT ライセンスのオープンソースで、使用料はかかりません。かかるのは、動かすためのサーバー（VPS など）の費用と電気代だけです。

Q. 自宅の Windows パソコンでも動きますか？ A. 公式は Windows 10（x64）に対応しています。ただし、パソコンを閉じたりスリープしたりすると監視も止まります。24時間動き続ける場所に置く のが前提です。

Q. 監視の間隔は何秒にすればいいですか？ A. 個人のサイトなら 既定の60秒で十分 です。短くするほど早く気づけますが、監視先へのアクセスも増えます。他人のサイトを短い間隔で監視するのは避けましょう。

Q. 外部のサイトも監視できますか？ A. URL を入れれば監視できますが、監視してよいのは自分が管理するサイト にとどめるのがマナーです。相手のサーバーに繰り返しアクセスすることになるためです。

まとめ

Uptime Kuma の使い方のポイントをまとめます。

• 正体：自分のサーバーに置く、無料・オープンソースの死活監視ツール
• 最新版：2.5.11（2026年11月12日公開。セキュリティ修正を含む）
• 構築：Docker で louislam/uptime-kuma:2。latest タグは v1 なので使わない
• データベース：個人なら SQLite で十分。後から MariaDB への移行は公式には非対応
• 監視：HTTP(s) は 間隔60秒・再試行1〜2 が目安。DNS 監視で名前解決の異常にも気づける
• 通知：Discord の Webhook URL を貼って「テスト」 で確かめ、各監視で通知をオンに
• 公開：ステータスページ でログイン不要の稼働状況ページを作れる
• 運用：監視先とは別の場所に置く・こまめに更新・/app/data をバックアップ

まずは、自分が管理しているサイト1つに HTTP 監視と Discord 通知を付けるところから始めてみてください。置き場所の VPS がまだなら、VPS の比較記事も参考になります。

あわせて読みたい

【2026年版】ConoHa VPS・さくらのVPS・Xserver VPS 徹底比較、初心者にはどれが向いている？

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。