Uptime Kumaは自分のサーバーで稼働状況を見張る監視ツール
Uptime Kumaは自分のサーバーでWebサイトやサービスを監視し、障害を通知してステータスページも公開できます。
ひと目でわかる
- これは何？
- louislam/uptime-kumaのREADMEをもとに、監視対象、通知、ステータスページ、Dockerと非Docker導入、運用上の境界を整理する。
- 誰に向いている？
- Uptime Kumaは、Webサイトやネットワークサービスの状態を自分のサーバーで確認し、異常を複数の通知先へ送りたい人に向く。Docker Compose、単独のDocker、Node.jsとPM2の導入経路があり、ステータスページや2FAも用意されている。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に JavaScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
自分の環境に置く監視画面という設計
Uptime Kumaは、Webサイトとサービスの状態を自分のサーバーで確認するセルフホスト型監視ツールです。READMEは使いやすさを前面に出し、作者がUptime Robotに似た自前の監視ツールを探していたこと、安定して保守されている選択肢を作りたかったことを動機として説明しています。UIにはVue 3、vite.js、Bootstrap 5を使い、REST APIではなくSPAでWebSocketを試したという背景も記載されています。
この経緯から、Uptime Kumaは監視ロジックだけでなく画面の見やすさを重視したプロジェクトだと読めます。取得時点のメタデータでは、JavaScript製、MITライセンス、masterブランチ、90,715スター、8,300フォーク、791件の未解決issueです。数字は公開活動の規模を示す手掛かりですが、通知の到達性や障害時の復旧を保証するものではありません。
一つの監視画面で複数のプロトコルを扱う
READMEに列挙されている監視対象は、HTTPとHTTPS、TCP、HTTPキーワード、HTTP JSONクエリ、WebSocket、Ping、DNSレコード、Push、Steamゲームサーバー、Dockerコンテナです。Webページの応答だけでなく、特定文字列、JSONの値、名前解決、コンテナ状態まで対象を分けて確認できます。Pingチャート、証明書情報、プロキシ対応、20秒間隔も機能一覧にあります。
監視の結果を伝える通知先として、Telegram、Discord、Gotify、Slack、Pushover、SMTPメールが挙げられ、90以上の通知サービスへのリンクもあります。複数のステータスページを作り、特定ドメインへ割り当てることもできます。READMEは監視タイプごとの細かな設定例や、20秒間隔を変更できるかどうかまでは記載していません。必要な判定条件と通知遅延は、導入後に実際の対象へ小さな監視を置いて確認する項目です。
Docker Composeは短い手順でサービスを公開する
Docker Composeによる導入では、uptime-kumaディレクトリを作り、GitHubからcompose.yamlを取得してdocker compose up -dを実行します。READMEの例では、サービスはネットワーク上の全インターフェースで動作し、localhost:3001またはサーバーのIPアドレスとポート3001からアクセスできます。単独のDockerコマンドでは、louislam/uptime-kuma:2イメージを起動し、uptime-kumaボリュームを/app/dataへ割り当てます。
外部へ公開する必要がなければ、127.0.0.1:3001へバインドしてlocalhostだけに制限できます。データ保存先についてREADMEは、NFSのようなネットワークファイルシステムをサポートせず、ローカルディレクトリまたはボリュームを使うよう警告しています。公開アドレス、ボリュームの場所、コンテナ版を先に決め、管理画面へ到達できる範囲を確認してから監視対象を登録するのが安全です。
Node.jsとPM2でコンテナを使わず動かす
非Docker環境では、Debian、Ubuntu、Fedora、ArchLinuxなどの主要Linuxディストリビューションと、Windows 10 x64、Windows Server 2012 R2 x64以上が対象です。Node.js 20.4以上、Git、バックグラウンド実行用のpm2が必要とREADMEにあります。FreeBSD、OpenBSD、NetBSD、Replit、Herokuはサポート対象外と明記されています。
導入の流れは、リポジトリをgit cloneし、npm run setupを実行してからnode server/server.jsで試すか、pm2 start server/server.js --name uptime-kumaで常駐させる形です。pm2 monitでコンソール出力を見たり、pm2 startupとpm2 saveで起動時の自動開始を設定したりできます。リバースプロキシや追加の導入オプションはWikiへ案内されています。Docker版と非Docker版を比較するときは、監視データの保存場所、更新方法、プロセスの再起動方法を同じ表にして確認したいところです。
ステータス公開と認証を運用の境界に置く
Uptime Kumaには複数のステータスページ、多言語、2FA、証明書情報、プロキシ対応があります。自分のチームが内部で見る監視画面と、利用者へ障害状況を知らせる公開ページを同じ仕組みで扱える構成です。READMEには一時的なライブデモも案内されていますが、デモのデータは10分後に削除されるものです。操作感を見る入口と、自分のサーバーを運用する証拠は分けて考えます。
監視画面やステータスページを全インターフェースで開く場合は、誰が設定を変更できるか、どのドメインを公開するか、通知に含まれる情報は何かを決めます。2FAがあることは確認できますが、READMEだけでは認証情報の保管、セッション管理、公開ページの詳細なアクセス制御までは評価できません。ステータスページを外部へ出すときは、内部ホスト名や障害原因を出しすぎない表示へ調整し、解除後の見え方も確認する必要があります。
更新とトラブル時の情報源を先に決める
Uptime Kumaの更新手順はREADME本文ではなく、GitHub WikiのHow to Updateページへ案内されています。直近のリリースとして2.5.3、2.5.2、2.5.1が取得データに記録されています。更新前には監視設定と保存データを退避し、通知が届く対象を少数に絞った確認環境で、監視、アラート、ステータスページ、ログインを順に確かめると差分を追いやすくなります。
一般的な質問や技術的な相談について、READMEは作者へのメールではなく、検索、GitHub Issues、Uptime Kumaのsubredditを推奨しています。バグ報告や機能要望はIssue、翻訳はWeblate、貢献者向けにはプルリクエストのガイドラインがあります。直近のリリース番号や多数のフォークだけで更新の安全性を判断せず、採用する版、戻す版、責任者、通知経路を自分の運用記録に残します。
MITライセンスでも監視責任は利用者に残る
リポジトリはMITライセンスで公開されています。著作権表示と許諾表示を含めることを前提に、使用、複製、変更、統合、公開、配布、サブライセンス、販売を検討できる条件です。一方、ソフトウェアは現状のまま提供され、商品性、特定目的への適合性、非侵害を含む保証はありません。ライセンスは監視対象の可用性や通知の到達を保証する文書ではありません。
本番で使う場合、監視サーバー自体が止まったときに気付けるか、設定と履歴をどうバックアップするか、通知サービスが失敗したときの別経路を用意するかが別の課題になります。READMEは20秒間隔と多様な監視機能を示しますが、保存ポリシーや性能基準は示していません。まずlocalhostに限定した環境で一つのHTTP監視と一つの通知を確認し、公開範囲、復旧、更新を検証してから対象を増やすのが堅実です。
編集部の結論
Uptime Kumaは、Webサイトやネットワークサービスの状態を自分のサーバーで確認し、異常を複数の通知先へ送りたい人に向く。Docker Compose、単独のDocker、Node.jsとPM2の導入経路があり、ステータスページや2FAも用意されている。一方、READMEには保存データの復旧計画、監視間隔の変更方法、本番負荷の基準はないため、公開範囲とバックアップを自分の環境で確認してから運用したい。
コミュニティノート