Uptime Kuma：把監控、告警與狀態頁收進同一個自架面板

如果你手上有一組自己維運的服務，不管是 API、網站、內部工具，還是跑在 Docker 裡的背景工作，遲早都會遇到一個很現實的問題：你到底要怎麼第一時間知道它掛了。

很多團隊一開始會把監控拆得很散：有的看主機，有的看應用，有的看 DNS，有的靠 Telegram 或 Discord 收通知，狀態頁又是另外一套服務。工具越多，維運成本就越高，最後很容易變成「出了事才知道去哪裡看」。我認為 Uptime Kuma 之所以值得寫成文章，不是因為它功能多，而是它把這些本來很分散的需求收斂成一個非常直覺的入口：一個自架監控面板，同時解決監控、告警、狀態頁與通知整合。

Uptime Kuma 在官方 README 裡的定位很直接：它是一個 easy-to-use 的 self-hosted monitoring tool。它支援的監控類型也不只 HTTP(s)，還包含 TCP、HTTP(s) Keyword、HTTP(s) Json Query、WebSocket、Ping、DNS Record、Push、Steam Game Server，甚至 Docker Containers。對我來說，這代表它不是只做「網站活不活著」這件事，而是把很多常見的線上健康檢查都放進同一個工作流裡。

我會先把它理解成什麼

如果用一句話概括，Uptime Kuma 更像是「輕量級的可觀測性入口」，而不是完整的 observability 平台。這個差異很重要。它非常適合拿來做：

服務存活檢查
簡單的故障告警
對外狀態頁
多通知管道整合
個人專案或小團隊的第一層防線

但它不是用來取代完整的 logs、metrics、trace 系統。也就是說，我會把它放在「能不能立刻知道服務出事」這個層級，而不是「為什麼出事」的完整診斷層級。這樣看它，定位會清楚很多。

為什麼它容易變成第一個自架監控工具

我認為 Uptime Kuma 的價值在於，它把三件常常要分開想的事綁在一起：

1. 監控類型夠實用

很多真實場景並不是只有 HTTP 200/500 這麼簡單。你可能需要看：

API 的關鍵字是否還在回應裡
某個 JSON 欄位是否還符合預期
WebSocket 連線是否正常
DNS 記錄是否還能解析
某台 Docker 容器是不是還活著
Steam Game Server 是否還在回應

Uptime Kuma 直接把這些都列在官方功能裡，對於自架服務來說很貼近需求。它讓你不用為了不同檢查項目再去拼湊一堆不同工具。

2. 告警整合夠廣

官方 README 寫得很清楚，它支援 Telegram、Discord、Gotify、Slack、Pushover、Email（SMTP）以及 90＋通知服務。這件事很實際，因為真正麻煩的通常不是「有沒有監控」，而是「訊號能不能到人」。

如果你已經有固定的工作通知管道，Uptime Kuma 通常可以直接接上，不需要再寫一層轉接服務。這會讓它很適合放在開發者團隊、個人 Side Project，甚至是小型 SaaS 的基礎維運流程裡。

3. 狀態頁很容易落地

很多團隊最後都會卡在對外說明。服務真的出事時，你總不能只在內部聊天群組說「我們知道了」。Uptime Kuma 提供多個 status pages，還可以把狀態頁對應到特定網域。這表示它不是只做內部告警，而是把對外溝通也一起收進來。

對產品或服務來說，這很重要。因為外部使用者看到的是「有沒有一個可信的公開狀態頁」，不是你內部 Slack 上有沒有紅色訊息。

最快的上手方式：Docker Compose

如果你只是想先把它跑起來，我會建議直接從 Docker Compose 開始。官方 README 的步驟非常短：

mkdir uptime-kuma
cd uptime-kuma
curl -o compose.yaml https://raw.githubusercontent.com/louislam/uptime-kuma/master/compose.yaml
docker compose up -d

跑起來之後，預設會在 http://localhost:3001 或你的主機 IP 的 3001 port 提供介面。

這個做法的好處是，你不用先研究太多安裝細節，就能先看到 UI、先加第一個監控項目、先測試通知管道。對大多數人來說，這才是有沒有真的導入成功的關鍵。

我會提醒的兩個實務細節

第一，官方明確提醒 NFS 不支援。

如果你習慣把資料掛在 NFS 上，這裡要小心。官方 README 提醒 File Systems like NFS are not supported，建議改用本地目錄或 volume。這不是小註解，而是會直接影響部署穩定性的限制。

第二，如果你要限制只在本機開放，要注意 port 綁定。

官方也給了範例，像是把 3001 綁到 127.0.0.1，這對內網測試或先在跳板機上試跑很實用。這種細節看起來不大，但在實際部署時常常能幫你少踩一個權限洞。

如果不用 Docker，也可以，但門檻更高

Uptime Kuma 也支援非 Docker 安裝，不過我會把它視為「你真的知道自己在做什麼時才選」的路線。

官方列出的需求包括：

Linux、Windows 等支援平台
Node.js 20.4 以上
Git
pm2，用來在背景執行

README 裡也給了 PM2 的安裝與啟動方式。這代表它確實可以跑在傳統 Node.js 環境裡，但如果你的目標只是快速導入，我還是會優先建議 Docker。原因很簡單：監控工具本身應該盡量降低安裝複雜度，不要讓第一道門檻就卡住。

實際導入時，我會怎麼安排第一步

如果是我自己導入，我不會一開始就想把所有監控都搬進去。我會先做三件事：

第一步：先監控最重要的服務

先挑一個最容易被使用者感知的 endpoint，例如首頁、登入頁、API health endpoint，或某個核心 webhook。先讓「服務有沒有活著」這件事被可靠地看見。

第二步：先接一個通知管道

我會先接 Telegram 或 Discord，因為它們通常最容易被團隊日常使用。先讓告警確實送得到人，再去考慮更多管道。

第三步：再做狀態頁

等第一層監控穩定之後，再把對外的 status page 建起來。這樣你不會一開始就把 UI、通知、監控全部同時上線，排錯會更容易。

這種做法的重點不是功能，而是降低導入成本。很多工具失敗，不是因為功能不夠，而是一次上太多東西，最後沒有人真的把它維運起來。

它特別適合誰

我會把 Uptime Kuma 推給以下幾種人：

有自架服務、需要簡單健康檢查的人
想要一套統一告警入口的小團隊
需要對外狀態頁，但不想維護太重基礎設施的人
想替 Side Project 建立最小可行監控的人
想把 Docker 容器、HTTP endpoint、DNS 與通知整合在一起的人

相反地，如果你的需求是大規模指標分析、SLO 管理、分散式 tracing，或是複雜的事件關聯分析，那 Uptime Kuma 可能只會是入口，不會是完整答案。

我喜歡它的原因，不是因為它花俏

我覺得這類工具最有價值的地方，通常不是它看起來多先進，而是它是否真的把「出事時要怎麼處理」變簡單了。Uptime Kuma 的設計很像這樣：

先把監控做直覺
再把通知做完整
最後把狀態頁做成可對外溝通的出口

這三件事合在一起，就足以覆蓋很多人最常見的需求。尤其在自架環境裡，你常常不是缺少工具，而是缺少一個「夠輕、夠快、夠清楚」的整合面板。Uptime Kuma 的強項，就是把這個入口做得足夠低摩擦。

結論

如果你正在找一個能快速落地的自架監控工具，我會把 Uptime Kuma 視為非常值得先試的選項。它不是最重的 observability 平台，但它在「服務監控、告警通知、狀態頁」這三件事上，已經把大部分人真正需要的核心需求包好了。

對個人專案來說，它可以是第一個正式上線的監控入口。對小團隊來說，它可以是把故障訊號收斂起來的中心。對想控制資料與基礎設施的人來說，它也提供了足夠簡單的自架起點。

我會這樣總結：如果你想把服務監控從零散工具變成可維護的系統，Uptime Kuma 是一個很務實的起點。

參考資料