Uptime Kuma 與 Healthchecks.io，自架服務監控的通知差異
以下各章節就會沿著這條線，逐一對照兩套工具的做法。
二、兩套工具的基本定位與架構差異
在談通知之前，必須先理解兩者的監控模型。因為「通知是怎麼被觸發的」，本質上是由「監控是怎麼被判斷的」決定的。
Uptime Kuma 的監控模型：主動探測為主、推送為輔
Uptime Kuma 是一套以 Node.js 撰寫的自架監控工具，前端是 Vue 驅動的即時介面，資料預設存在 SQLite（新版本也支援 MariaDB）。它的核心行為是：由 Uptime Kuma 這個監控主體，週期性地去「戳」被監控的目標。
它支援的監控類型非常雜，大致可以分成幾類：
因為是主動探測，Uptime Kuma 有一個天然的優勢：它知道「壞掉的時候長什麼樣子」。HTTP 監控可以記錄狀態碼、回應時間、憑證到期日、Response Body 關鍵字比對結果；TCP 監控可以記錄連線失敗的原因。這些資訊都可以塞進通知內容裡，讓收到告警的人在第一時間判斷嚴重程度。
但它也有一個天然的弱點：如果 Uptime Kuma 自己所在的機器或網路掛掉，它就沒辦法通知你它掛掉了。這是所有主動探測型監控的共通問題，實務上要靠異地部署或外部心跳來補。
Healthchecks.io 的監控模型：純粹的心跳與時間
Healthchecks.io 的定位非常明確：它不主動去看你的服務，它只等你來報平安。每一個 Check 都有一組專屬的 Ping URL，你的備份腳本、Cron Job、應用程式在執行成功後打一個 GET/POST 到這個 URL，Healthchecks 就記錄下「在這個時間點，有人回報活著」。
它的狀態機比多數人想像的細緻：
New：剛建立、還沒收到任何 Ping。
/start）。Up：在預期時間內收到 Ping。
Down：超過預期時間加上寬限期，仍然沒有收到 Ping。
Paused：手動暫停，常用於維護窗口。
這個模型的最大價值在於：它能捕捉「什麼都沒發生」的故障。備份腳本沒跑、Cron 被系統砍掉、系統時鐘跑掉導致排程沒觸發——這些都不會讓任何端口不通，但心跳會停，於是通知會響。相對地，Uptime Kuma 的 Push 監控雖然也有類似能力，但它在整個產品裡只是眾多監控類型之一，而不是核心設計哲學。
Healthchecks.io 本身有雲端付費版，同時也以開源專案形式提供自架版（可自行以 Docker 部署）。自架版的功能相當完整，包含多使用者、多專案、整合管理、狀態頁等，但部分整合需要你自己填入 API 憑證，也沒有雲端版的維運團隊幫你顧著「通知有沒有真的送出去」。
三、通知管道對照：誰支援得多、誰整合得深
這是最多人關心的表面問題：到底誰支援的通知服務比較多？先說結論——Uptime Kuma 在「通知服務數量」上大幅領先，Healthchecks.io 在「通知事件的細緻度」上更有想法。
Uptime Kuma 的通知渠道清單與特性
Uptime Kuma 內建的通知服務清單長到誇張，而且版本更新時經常追加。以目前常見的版本來說，大致包含（族繁不及備載）：
數量上的優勢在實務上很有感。舉例來說，台灣與中文圈使用者常用的 Telegram Bot、企業微信、釘釘、Bark，Uptime Kuma 都是「填一填參數就能用」的原生整合；而在 Healthchecks.io 上，這些往往要繞道 Webhook 或第三方橋接。
Uptime Kuma 的通知設定還有幾個實用的細節：
Healthchecks.io 的整合清單與特性
Healthchecks.io 的整合數量少得多，但每一個都做得相對紮實，大致涵蓋：
Email（自架版走自己的 SMTP 設定）
Webhooks（可自訂 POST 內容，也支援 GET）
SMS（透過 Twilio 等簡訊服務商，需要自備帳號）
看起來也不算少，但關鍵差異在「整合的管理方式」。Healthchecks.io 的整合是在專案（Project）層級建立，然後透過 Tag 篩選決定哪些 Check 的事件要送到哪個整合。這個設計乍看之下多了一層抽象，但它換來的是非常強大的路由能力——這點我們留到第六章細談。
另一個值得注意的是 Apprise 支援。Apprise 是一個 Python 寫的通用通知函式庫，支援上百種通知服務。Healthchecks.io 直接內建 Apprise 整合，等於把「通知服務清單」的擴充性外包給了一個成熟的社群專案。這對自架玩家來說是很聰明的做法：你想要的通知管道，只要能寫進 Apprise 的 URL 格式，就能接上。
自架情境下真正關鍵的幾條管道
清單長不代表一定用得上。以台灣自架社群的實際使用習慣來看，真正會天天用到的其實就那幾條：
在這幾條「真正會用」的管道上，兩者都能勝任，差別只在設定的繁瑣程度與訊息格式的豐富度。
四、觸發邏輯差異：狀態機、重試與去重
這是本文最核心的章節。通知管道再多，如果觸發條件設計得不好，你只會得到兩種結果：要嘛漏報，要嘛被淹沒。
Uptime Kuma 的失敗判定與重試機制
Uptime Kuma 對一個監控項的失敗判定，主要看「連續失敗次數」。在監控設定裡有幾個關鍵欄位：
Retries：連續失敗幾次才判定為 Down（例如 3 次）。
舉個例子：Interval 設 60 秒、Retries 設 3、Retry Interval 設 60 秒，那麼一次真正的故障要等到「連續三次探測失敗」才會觸發通知，也就是最快約 3 分鐘後才會響。這段延遲換來的是降噪——避免網站偶爾回應慢半拍就發通知。
但要注意：Uptime Kuma 的 Retries 是「監控層」的概念，不是「通知層」的概念。它決定的是「什麼時候判定 Down」，而通知重試（Notification Retries）才是「通知發送失敗時重送」。兩者容易混淆，設定時要看清楚是在哪個頁面。
對於 Push（心跳）型監控，Uptime Kuma 的判定則是「超過預期時間沒有收到 Ping 就判定 Down」，同樣可以搭配 Retries 使用。不過它的細緻度不如 Healthchecks.io 的 Grace / Started 狀態機。
Healthchecks.io 的 Grace Time、鬧鐘狀態與失敗閾值
Healthchecks.io 的觸發邏輯圍繞著三個欄位打轉：
Period：預期的執行間隔（例如每 24 小時一次備份）。
它的狀態轉換是這樣的：Up → 到了預期時間但沒收到 Ping → 進入 Grace → Grace 結束仍沒收到 → Down 並觸發通知。若在 Grace 期間內收到 Ping，狀態直接回到 Up，不會產生任何通知。這點非常關鍵：Grace Time 本質上就是 Healthchecks.io 的「失敗閾值」，只是它用時間來表達，而不是用次數。
此外，Healthchecks.io 還有一個 Uptime Kuma 沒有的概念：「Started」狀態。如果你的腳本在開始執行時打 /start、執行太久時打 /log，Healthchecks 可以針對「執行時間過長」這種情境發出通知。對於長時間執行的 ETL 或轉檔任務，這是很實際的告警條件。
Healthchecks.io 也有「重複通知（Repeat Notifications）」的概念：當 Check 處於 Down 狀態時，可以設定每隔多久重送一次提醒，直到恢復為止。不過它是綁在整合（Integration）層級設定，而不是每個 Check 獨立設定。
抖動（Flapping）與通知風暴的處理
「服務在 60 秒內掛掉又活過來、又掛掉」這種情況，是告警系統最頭痛的情境。兩套工具的處理策略不同：
Uptime Kuma 靠的是 Retries 與 Retry Interval 的組合。只要把連續失敗次數拉高，短暫的抖動就會被吸收掉。另外它也有「維護窗口（Maintenance Window）」功能，可以在預定的維護時段內暫停通知，避免工程師自己動手時被自己的告警吵。
Healthchecks.io 靠的是 Grace Time。把 Grace 設得比抖動週期長，就能吸收掉大部分誤報。它也有 Pause 功能，可以手動暫停 Check，但沒有 Uptime Kuma 那種「排程式維護窗口」的概念（自架版可透過 API 腳本搭配 Cron 來模擬）。
實務建議：如果你的服務本身不穩定、經常短暫 timeout，Uptime Kuma 的 Retries 設計比較直覺；如果你的服務是定時任務，Healthchecks.io 的 Grace Time 更符合「預期時間 + 容忍誤差」的思考方式。
五、通知內容與訊息可讀性
一則好的告警通知應該要在三秒內回答四個問題：哪個服務掛了？什麼時候掛的？掛得多嚴重？我該去哪裡看？
告警訊息欄位與模板
Uptime Kuma 的通知內容相對豐富，以 Telegram 為例，預設訊息會包含：監控名稱、狀態（Down / Up）、發生時間、監控類型、目標 URL 或主機位址、錯誤訊息（例如 HTTP 500、連線逾時）、Response Time。若是 HTTP 監控，還能看到狀態碼與憑證資訊。它的 Webhook 通知更可以自訂 JSON 模板，把欄位接到自家系統。
Healthchecks.io 的通知內容則以「心跳」為中心：Check 名稱、目前狀態、最後一次 Ping 的時間、預期間隔、所屬專案、Tags。它的優勢在於事件語意很清楚——一則通知會明確告訴你「這個 Check 從 Up 變成 Down 了」，或「恢復了」。有些整合甚至會標示這是一次「新的故障」還是「重複提醒」。
Uptime Kuma 的訊息比較「技術細節導向」，Healthchecks.io 的訊息比較「狀態機導向」。前者適合排查、後者適合值班。
恢復通知與每日／每週報告
恢復通知常被忽略，但它其實是告警疲勞的救星。如果只有 Down 通知沒有 Up 通知，你會在問題修好之後仍然處於「不知道到底好了沒」的焦慮中，最後乾脆把整個告警頻道靜音。
Uptime Kuma 支援在每個通知設定中勾選是否發送「恢復通知（Recovery / Up）」，預設是開啟的。Healthchecks.io 同樣支援 Up 通知，而且在整合層級可以分別選擇「Down 時通知」「Up 時通知」「Grace 時通知」，顆粒度更細。
另一個實用功能是定期報告。Healthchecks.io 提供每日與每週的摘要報告，把「這段期間內有哪些 Check 出過事、恢復時間多長」彙整成一封信。這對於沒有專職值班人員的小團隊很有幫助——不需要即時盯著，只要每天早上花三分鐘看報告就好。Uptime Kuma 本身沒有類似的內建報告功能，必須靠狀態頁或外部工具補足。
六、路由與分級：誰能做得更細
當監控項從 3 個長到 30 個，路由能力就變成剛需。你總不能讓「NAS 硬碟空間不足」跟「公司官網掛掉」發到同一個群組吧。
Uptime Kuma 的 Per-Monitor 通知與通知群組
Uptime Kuma 的路由邏輯很直白：每個監控項可以勾選要發到哪幾個通知。你可以建立多個通知設定（例如「Telegram - 維運組」「Telegram - 老闆」「SMTP - 每日摘要」），然後在個別監控中勾選。同一個監控也可以同時發到多個通知管道，這點對於「重要服務要多管道備援」的需求很友善。
它的限制在於：沒有 tag、沒有群組、沒有規則引擎。當監控項上百個時，你得一個一個點開勾選，維護成本會直線上升。社群常見的變通做法是：
[DB] PostgreSQL-Main），靠人腦分類。把 Webhook 接到 n8n / Node-RED，用自動化流程做二次分流。
直接分成多個 Uptime Kuma 實例，用「實例」當成最粗的分類層級。
Healthchecks.io 的 Tag-based Routing
Healthchecks.io 的路由設計明顯更「工程師思維」。每個 Check 可以掛多個 Tags，而每個整合（Integration）可以設定 Filter Tags，只有符合條件的 Check 事件才會被送到該整合。例如：
整合 A：Filter Tags 設為 db，只接資料庫相關的告警。
整合 B：Filter Tags 設為 backup，只接備份任務的心跳。
critical，接所有標記為關鍵的 Check，並送到 PagerDuty。這種設計的擴充性非常好：新增一個 Check 時，只要掛上對應的 tag，通知路由就自動生效，不需要回頭改任何整合設定。當你的監控規模從 10 個成長到 200 個，這個差異會非常明顯。
不過要注意，Healthchecks.io 的自架版本在整合管理上仍是以專案為單位，跨專案的路由需要靠多個專案或 API 來處理。另外它的「每個 Check 只能屬於一個專案」的設計，也讓跨團隊共用時需要稍微規劃一下。
如果單純比較「路由顆粒度」，結論是：少量監控 → Uptime Kuma 直覺好用；大量監控 → Healthchecks.io 的 tag 路由明顯勝出。
七、自架部署與通知可靠性的實務眉角
不管你選哪一套，自架版都會面臨同樣的問題：通知管線是自己維護的，所以斷在哪一環你都得自己查。以下整理幾個實務上一定會踩到的坑。
部署方式與資源佔用
Uptime Kuma 官方提供 Docker Image，一行 docker run 就能跑起來，SQLite 資料存在掛載的 volume 裡。它的資源佔用不高，一台 1GB RAM 的小 VPS 可以輕鬆跑，但如果監控項很多（數百個），還是建議給到 2GB 並考慮改用 MariaDB。
Healthchecks.io 自架版同樣有官方 Docker Image，但它的部署稍微複雜一點：需要 MySQL 或 PostgreSQL、需要設定 Django 的環境變數（SECRET_KEY、ALLOWED_HOSTS、EMAIL_* 等）、需要處理靜態檔案與背景工作程序。官方文件寫得算完整，但第一次部署大概要花上一兩個小時。
以下是一個簡化的 Healthchecks.io 自架 compose 骨架（示意用，實際請依官方文件調整）：
services:
db:
image: postgres:15
environment:
POSTGRES_DB: hc
POSTGRES_USER: hc
POSTGRES_PASSWORD: change-me
volumes:
- hc-db:/var/lib/postgresql/data
web:
image: healthchecks/healthchecks:latest
depends_on:
- db
environment:
DB: postgres
DB_HOST: db
DB_NAME: hc
DB_USER: hc
DB_PASSWORD: change-me
SECRET_KEY: change-me-too
ALLOWED_HOSTS: hc.example.com
SITE_ROOT: https://hc.example.com
EMAIL_HOST: smtp.example.com
EMAIL_PORT: 587
EMAIL_HOST_USER: [email protected]
EMAIL_HOST_PASSWORD: change-me
ports:
- "8000:8000"
volumes:
- hc-data:/data
volumes:
hc-db:
hc-data:
Uptime Kuma 的部署就單純很多：
services:
uptime-kuma:
image: louislam/uptime-kuma:1
volumes:
- ./uptime-kuma-data:/app/data
ports:
- "3001:3001"
restart: unless-stopped
但別忘了：把監控服務跟被監控的服務放在同一台機器上，等於自廢武功。如果那台機器停電，Uptime Kuma 跟其他服務一起消失，你不會收到任何通知。務必把監控節點放在另一台機器、另一家 VPS，或至少另一個網路環境。
通知備援與避免漏報的三層設計
再可靠的工具，通知管道本身都可能出問題：Telegram Bot Token 被撤銷、SMTP 被標記為垃圾郵件、Webhook 目標服務掛掉。建議用三層備援來設計：
第一層：主要即時通道。Telegram 或 ntfy，要求「快」。
在 Uptime Kuma 裡，這可以透過「同一個監控掛多個通知」來實現；在 Healthchecks.io 裡，則是「同一個 tag 掛多個整合」。兩者都能做，只是設定的方式不同。
另外一個常被忽略的招式是 「心跳的反向驗證」：讓 Healthchecks.io 每小時發一封「系統正常」的 Ping 給你的 Uptime Kuma，或反過來。這聽起來有點繞，但它能偵測到「通知服務本身掛掉」的情況——如果你的 Telegram Bot 失效，你會發現「應該要來的測試訊息沒來」，比等到真的出事才發現好得多。
八、選型建議與混搭架構
看到這裡，你大概已經有感覺：這兩套工具不是替代關係，而是互補關係。以下給出比較明確的選型建議。
什麼情況該選 Uptime Kuma
你有一堆用 HTTP、TCP、Docker 跑的服務，需要「主動探測 + 狀態頁」。
你想要在同一個介面看到所有監控的歷史圖表、回應時間、憑證到期日。
你需要豐富的即時通訊整合（尤其是中文圈常用的釘釘、企業微信、飛書、Bark）。
你希望部署與維護成本越低越好，不想碰 Django 環境變數。
你重視「漂亮的狀態頁」對外展示。
什麼情況該選 Healthchecks.io
你的核心需求是「定時任務有沒有跑」，例如備份、憑證更新、資料同步、報表產生。
你有很多 Cron Job，而且希望它們出問題時能精準告警。
你需要 tag 路由來管理數十上百個心跳檢查。
你重視每日／每週摘要報告，想用低干擾的方式掌握整體健康度。
你偏好「狀態機式」的明確語意（Up / Grace / Down / Started）。
兩者併用的實務配置範例
以一個典型的中小型自架環境為例，我會這樣配置：
backup、cert、report，分別路由到不同整合。這樣的架構兼顧了「服務掛掉要馬上知道」與「任務沒跑要事後知道」兩種需求，而且通知管道可以刻意錯開（例如 Uptime Kuma 走 Telegram、Healthchecks.io 走 Discord + Email），避免單一管道故障造成全面失聯。
九、結語：通知設計比工具選擇更重要
回到本文的主題——通知差異。總結來說：
Uptime Kuma 的通知優勢在「廣度」：支援的服務多、每個監控可獨立掛通知、訊息內容富含技術細節、有通知重試與重複通知、有測試按鈕可以驗證管道。它適合當作「主動探測型監控的統一通知出口」。
Healthchecks.io 的通知優勢在「深度」：狀態機語意清楚、Grace Time 提供天然的降噪、tag 路由讓大規模管理變得優雅、每日／每週報告降低告警疲勞。它適合當作「定時任務與心跳監控的通知中樞」。
但真正決定成敗的，往往不是工具本身，而是 你怎麼設計那條從「事件發生」到「人被叫醒」的管線。有沒有區分嚴重等級？有沒有恢復通知？有沒有備援通道？有沒有定期驗證「測試訊息還收得到」？這些問題的答案，比「Uptime Kuma 跟 Healthchecks.io 哪個比較好」重要一百倍。
如果你只能選一套，先問自己：我的服務主要是「一直在跑」的，還是「定時跑一次」的？前者選 Uptime Kuma，後者選 Healthchecks.io。如果你兩個都有（多數自架玩家都是），那就兩套都裝，讓它們各自負責擅長的戰場，再讓它們互相監視。這才是自架精神最迷人的地方——你不需要在別人的框架裡二選一，你可以自己組出剛剛好的那一套。
最後提醒一句：不管你選哪一套，裝好之後記得按一下測試按鈕，然後把測試訊息真的收到手機上。很多人的監控是在「出事那天」才第一次驗證通知管線，而那天通常已經太晚了。
💬 想說點什麼？
歡迎到留言板分享你的想法、心得或疑問。
💬 前往留言板 →