Upptime：基於 GitHub 的可用性監控與狀態頁
GitHub Actions 正常運作時間監視器和狀態頁面，作者：@AnandChowdhary。 Upptime**（是開源的正常運行時間監視器和狀態頁面，完全由 GitHub 操作、問題和頁面提供支持，由 Anand Chowdhary 製作。
秒懂
- 它是什麼？
- Upptime 使用 GitHub Actions 進行定時檢查，使用 GitHub Issues 追蹤事件，並使用 GitHub Pages 發佈公開狀態頁。
- 適合誰用？
- Upptime 展示了如何用 GitHub 自身的工具組裝完整的監控棧，倉庫成為可用性資料的唯一來源。 對 upptime 而言，先按 README 的專屬命令與檔案完成最小流程，再核對輸出、權限與失敗行為；不適合把未記載的平台支援或效能承諾當成既定事實。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Markdown（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
由 GitHub Actions、Issues 和 Pages 驅動
Upptime 是一個開源的可用性監控和狀態頁專案，完全運行在 GitHub 基礎設施之上。它使用 GitHub Actions 執行定時檢查，使用 GitHub Issues 記錄事件，並使用 GitHub Pages 承載公開的狀態網站。該專案由 Anand Chowdhary 建立，官方網站是 upptime.js.org。README 明確說明 Upptime 與 GitHub 無隸屬關係，也未經 GitHub 認可。設計目標是讓已經使用 GitHub 的使用者完全免費，不需要外部伺服器或訂閱。所有設定都儲存在一個檔案中，如果刪除倉庫，監控資料也會隨之消失。這個專案的思路是複用 GitHub 自帶的工具，而不是搭建一套獨立的監控服務。監控資料以 git 提交的形式存在，因此每一次檢查和響應時間的記錄都有跡可循。
針對「由 GitHub Actions、Issues 和 Pages 驅動」的第 1 個核對面向，Upptime 把網站監控資料放進 GitHub repository，以 GitHub Actions 執行檢查並用 GitHub Pages 發布狀態頁。採用前可用一個測試 repository 寫入 `.upptimerc.yml`，觀察 workflow、issue 與 status page 是否依預期更新。
在「由 GitHub Actions、Issues 和 Pages 驅動」這個範圍內，upptime 的核對點是第 1 節所列的輸入與輸出。README 沒有說明更細的相容性或效能保證，因此本文只把已記錄的命令、檔案與設定鍵當作可核對的範圍。
定時檢查與響應時間提交
監控工作流執行在 GitHub Actions 上。工作流每五分鐘存取一次每個設定的端點，以確認其線上。響應時間每六小時測量一次，並提交到倉庫的 git 歷史中，因此每個端點在 history 目錄下都有對應的檔案。每天會從這些資料產生響應時間圖表，GitHub API 將歷史資料提供給狀態頁。這意味著所有監控資料都存放在倉庫本身，刪除倉庫就會刪除這些資料。這種設計讓監控歷史成為倉庫的一部分，任何有許可權的人都可以透過 git 提交歷史檢視變化，形成原生的稽核軌跡。響應時間資料被記錄到單獨的檔案中，便於後續分析和視覺化。
針對「定時檢查與響應時間提交」的第 2 個核對面向，這種架構不需要另建監控伺服器，但檢查頻率、Actions 配額、GitHub Pages 可用性與事件延遲都成為依賴。README 所列功能不等於 SLA；若服務需要更短週期或私有網路探測，需另行驗證限制。
在「定時檢查與響應時間提交」這個範圍內，upptime 的核對點是第 2 節所列的輸入與輸出。README 沒有說明更細的相容性或效能保證，因此本文只把已記錄的命令、檔案與設定鍵當作可核對的範圍。
用 GitHub Issues 為事件報告
當端點出現故障時，工作流會自動開啟一個 GitHub issue。這個 issue 會分配給倉庫成員，以便相關人員看到。團隊成員可以在評論中新增事件報告，當網站恢復正常時，issue 會自動關閉。issue 會被鎖定，倉庫外的人無法評論，並且更新時會傳送 Slack 通知。README 展示了一個範例 issue，並描述了完整的生命週期。這個機制將事件報告和團隊協作直接放在 GitHub 的介面上，不需要額外的工單系統。事件的狀態變化都會反映在 issue 的時間線上，方便追溯。
針對「用 GitHub Issues 作為事件報告」的第 3 個核對面向，Upptime 把網站監控資料放進 GitHub repository，以 GitHub Actions 執行檢查並用 GitHub Pages 發布狀態頁。採用前可用一個測試 repository 寫入 `.upptimerc.yml`，觀察 workflow、issue 與 status page 是否依預期更新。
在「用 GitHub Issues 作為事件報告」這個範圍內，upptime 的核對點是第 3 節所列的輸入與輸出。README 沒有說明更細的相容性或效能保證，因此本文只把已記錄的命令、檔案與設定鍵當作可核對的範圍。
用 Svelte 構建狀態頁
狀態頁是一個漸進式 Web 應用，從倉庫生成。它使用 Svelte 和 Sapper 構建，並透過 GitHub API 從倉庫獲取資料。頁面顯示可用性百分比、響應時間圖表和事件歷史。README 稱其簡單、美觀且易存取，並託管在 GitHub Pages 上。即時示範在 demo.upptime.js.org。因為資料來自倉庫的 API，所以狀態頁的內容與倉庫中的記錄保持一致。PWA 的性質讓使用者可以將狀態頁新增到主畫面，並在離線時檢視已快取的資料。狀態頁的設計目標是讓任何訪客都能快速了解服務狀態。
針對「用 Svelte 構建狀態頁」的第 4 個核對面向，這種架構不需要另建監控伺服器，但檢查頻率、Actions 配額、GitHub Pages 可用性與事件延遲都成為依賴。README 所列功能不等於 SLA；若服務需要更短週期或私有網路探測，需另行驗證限制。
在「用 Svelte 構建狀態頁」這個範圍內，upptime 的核對點是第 4 節所列的輸入與輸出。README 沒有說明更細的相容性或效能保證，因此本文只把已記錄的命令、檔案與設定鍵當作可核對的範圍。
使用情況
README 報告說，Upptime 被超過 3000 個人和團隊使用，其中包括 Canonical 和 Wakatime，倉庫擁有超過 16000 顆星。它還引用了 CSS-Tricks 的一段話，稱 Upptime 是 GitHub Actions 的一個非常巧妙的用法。該專案設計為對 GitHub 使用者完全免費，無需外部伺服器或訂閱，所有設定都在一個檔案中。這個專案的吸引力在於它沒有引入新的託管成本，而是把監控邏輯嵌入到 GitHub 的既有流程中。使用者只需要維護一個設定檔，就能獲得監控、事件追蹤和狀態頁的功能。
針對「使用情況」的第 5 個核對面向，Upptime 把網站監控資料放進 GitHub repository，以 GitHub Actions 執行檢查並用 GitHub Pages 發布狀態頁。採用前可用一個測試 repository 寫入 `.upptimerc.yml`，觀察 workflow、issue 與 status page 是否依預期更新。
在「使用情況」這個範圍內，upptime 的核對點是第 5 節所列的輸入與輸出。README 沒有說明更細的相容性或效能保證，因此本文只把已記錄的命令、檔案與設定鍵當作可核對的範圍。
許可證
倉庫的程式碼使用 MIT 許可證，history 目錄中的資料使用開放資料庫許可證（ODbL），README 中對此有說明。MIT 許可證允許使用、複製、修改、合併、發佈、分發、再許可和銷售軟體副本，並包含標準免責宣告：軟體按「原樣」提供，不提供任何形式的保證。許可證文字不涵蓋歷史資料，歷史資料由 ODbL 另行管理。這意味著程式碼部分可以自由使用和修改，但監控資料的使用條款可能有所不同。使用者在貢獻或使用這些資料時需要留意相應的許可證要求。
針對「許可證」的第 6 個核對面向，這種架構不需要另建監控伺服器，但檢查頻率、Actions 配額、GitHub Pages 可用性與事件延遲都成為依賴。README 所列功能不等於 SLA；若服務需要更短週期或私有網路探測，需另行驗證限制。
在「許可證」這個範圍內，upptime 的核對點是第 6 節所列的輸入與輸出。README 沒有說明更細的相容性或效能保證，因此本文只把已記錄的命令、檔案與設定鍵當作可核對的範圍。
編輯結論
Upptime 展示了如何用 GitHub 自身的工具組裝完整的監控棧，倉庫成為可用性資料的唯一來源。 對 upptime 而言，先按 README 的專屬命令與檔案完成最小流程，再核對輸出、權限與失敗行為；不適合把未記載的平台支援或效能承諾當成既定事實。
社群筆記