Uptime Kuma vs UptimeRobot：自架監控與 SaaS 監控的取捨
監控器數量計價、檢查頻率、通知管道與狀態頁的差別，以及一個自架監控無法迴避的問題：監控服務自己掛了，誰來通知你？
🚀 想直接開始?一鍵部署你的專屬服務
免架伺服器、獨立容器、自動 SSL、月付不綁約。
網站監控這件事的邏輯很簡單：定時去戳你的網站，沒回應就通知你。真正的差別不在功能，而在計價方式，以及一個容易被忽略的結構性問題。我們先講功能，最後講那個問題。
差異一：計價邏輯
SaaS 監控服務（UptimeRobot、Better Stack 這類）幾乎都是依監控器數量分級：免費方案給你少量監控器與較長的檢查間隔，要更多就往上升級，通常以美元計價按月訂閱。
Uptime Kuma 是開源自架，成本是固定的伺服器費用，監控器數量不限。如果你要監控的是三個網站，SaaS 免費版就夠了；如果你要監控 40 個客戶的網站加上各自的 API 端點，兩者的成本結構會完全分開。
差異二：檢查頻率
SaaS 的免費或低價方案通常會限制最短檢查間隔（例如 5 分鐘）。這代表最糟的情況下，你的網站掛掉 5 分鐘後你才會知道。
Uptime Kuma 的檢查間隔由你自己決定，最短可到 20 秒。對於電商或金流這類每分鐘都算錢的服務，這個差別是實質的。
差異三：通知管道
Uptime Kuma 內建 90 種以上的通知整合，包含台灣團隊常用的 LINE、Telegram、Slack、Discord、Email、Webhook。SaaS 服務的通知管道通常也夠用，但部分管道會被放在較高的付費層級。
如果你要的是「掛掉直接推到公司的 LINE 群」，Uptime Kuma 設定起來相當直接。
差異四：狀態頁
兩者都能產生公開的狀態頁讓客戶自己查看服務可用率。Uptime Kuma 的狀態頁可以綁自己的網域、自訂樣式，而且不會出現對方的品牌標誌。如果你是接案或做 B2B 服務，這件事對專業形象有差。
那個結構性問題：誰監控監控服務？
這是自架監控無法迴避的一點，任何推薦 Uptime Kuma 卻不提這件事的文章都不夠誠實。
如果你把 Uptime Kuma 裝在跟你網站同一台伺服器上，那台機器掛掉的時候，你的網站和你的監控會一起消失——而且沒有人會通知你。你會以為一切正常，因為沒收到警報。
正確的做法有幾種：
- 放在不同的機器——最基本的要求。監控主機與被監控的服務必須獨立。
- 用 Push 監控做心跳——Uptime Kuma 支援 Push 模式，可以搭配外部的 cron 服務反向確認它自己還活著。
- SaaS 監控 Uptime Kuma 本身——用 SaaS 的免費方案監控你的 Uptime Kuma。這聽起來很繞，但只需要一個監控器，免費額度綽綽有餘，是很實際的組合。
第三種其實是最務實的答案：兩者不是互斥的。用 Uptime Kuma 監控你的幾十個服務，用一個 SaaS 免費監控器盯著 Uptime Kuma。
該怎麼選
| 你的情況 | 建議 |
|---|---|
| 只有 1～3 個網站要監控 | SaaS 免費方案就夠，不用自架 |
| 要監控很多服務，或客戶數量會成長 | Uptime Kuma，成本不隨數量上升 |
| 需要 1 分鐘內知道服務掛掉 | Uptime Kuma，檢查間隔自訂 |
| 需要品牌化的公開狀態頁 | Uptime Kuma |
| 完全不想維運任何東西 | SaaS |
