警示與管道

管道就是警示可以送達的地方。您要新增多少都可以，接著再為每個監控項目分別選擇哪些屬於例行通知、哪些用於警示升級。

您可以新增哪些管道

這些由您自己在「設定 → 通知」中新增：

電子郵件——任何地址。
Slack、Teams、Discord——來自該應用程式的傳入 webhook URL。
Telegram——一個聊天，透過我們的機器人連結。
PagerDuty 與 Jira Service Management——一組整合金鑰。
Webhook——您自己的端點。僅限 HTTPS、附簽章，另見下文。

這些則由收訊的人自己新增，而不是由別人代為填寫：

推播——安裝行動應用程式並允許通知。
簡訊——登錄您自己的號碼，並確認我們傳到該號碼的驗證碼。
WhatsApp——同樣的做法，改用 WhatsApp。
衛星——Iridium、Inmarsat 或 Thuraya 手持機，經由網路業者的閘道以電子郵件送達。

管道屬於誰

每個管道不是屬於團隊，就是屬於某一個人，而這個差別決定了有人離開時會發生什麼事。

共用管道——一個 #alerts webhook、一項 PagerDuty 服務、一份群發清單——屬於組織，任何人離開後它都會留下來。

個人管道——一支手持機、一個私人的 Telegram 聊天、一個行動電話號碼——屬於登錄它的那個人，並且在該成員被移出組織時會一併刪除。在這項規則成立之前，已被移除的同事的 Telegram 聊天仍會無限期收到停機訊息，即使其成員資格與 API 金鑰早已撤銷。

所以在安排警示的去向時，請看清楚您送往的管道是誰的。負責接線呼叫的人，通常不是被它叫醒的那個人。

地址必須先同意，才會收到任何訊息

電子郵件、簡訊、WhatsApp 與衛星都會先行確認。新增一個電子郵件管道後，該地址只會收到剛好一則訊息——詢問它是否願意成為警示的收件地址——在它答應之前不會再收到任何東西。登錄電話號碼時，則由您把驗證碼輸入回來。

這麼做是因為電子郵件管道是某個人在另一個人的帳戶裡填進去的地址。若沒有這道關卡，一位編輯者就能把一個不斷跳動的監控項目指向陌生人的收件匣，而我們照送不誤。測試發送按鈕在地址確認之前同樣會被拒絕，理由相同：否則它就是一種無限次寄信給未經同意地址的方法，只是掛著一個看來很體貼的名字。

聊天管道與推播管道不會詢問，這並不是例外。貼上 Slack webhook URL 的人必須先握有它，而推播管道是由手持機的主人自己註冊的——這兩者都無法只靠輸入一個地址就指向陌生人。

已經屬於貴組織某位已驗證成員的地址會自動確認。他們在註冊時就已證明那是自己的地址。

簡訊與 WhatsApp

兩者都需要 Pro 以上方案，而且共用同一份額度——Pro 為每天 10 則、每週 15 則、每月 30 則；Business 與 Enterprise 則為 15、50 與 100 則。它們共用一份額度，是因為兩者都按則計費，也都送到同一支手機上，所以上限要防的那件事——單一個跳動的監控項目在一小時內花掉一個月的預算——不論走哪一條路都是同一件事。

採用三個時間窗而不是一個，是因為只用一個的形狀不對。只有每月上限，單一個跳動的監控項目一個下午就能把額度用光；只有每日上限，慢慢滴漏的警示會花掉您原本打算的三十倍。

上限在訊息排入佇列時就會生效，因此被擋下的訊息根本不會占用位置；計數依據的是實際送出的訊息，而不是一個計數器——計數器無法在呼叫別人的 API 這件事上維持誠實。

簡訊並非到處都能送達，我們會在您登錄之前就說明

簡訊的可達性取決於收件人所在的國家。有些電信網路根本不會承載來自我們這類寄件者的訊息；另一些則只接受來自已向當地主管機關登記之寄件者名稱的訊息。國家選單只會列出我們認為送得到的目的地，定價頁面上有完整清單。

凡是寄件者名稱可能被替換成本地號碼的地方，我們都會在登錄時就告訴您，而不是讓您從一則來自陌生號碼的訊息中發現。WhatsApp 完全沒有這些限制，在任何地方都不需要登記，而且簡訊到不了的每個國家它都到得了。

警示絕不包含連結。電信業者會過濾未知的 URL，而被過濾掉的警示就是您永遠收不到的警示——所以名為 acme.com 的監控項目會以 acme com 的形式送達。

衛星

適用於完全沒有行動網路可用的手持機。訊息經由業者的閘道以電子郵件送出，因此您付的是電子郵件的費率而不是簡訊費率——但業者把投遞上限訂在每支手持機每天五則，那是他們的限制而非我們的，而且每則訊息都會被截到 160 個字元。

回應異常緩慢

一個監控項目可能每次檢查都通過，卻仍然有問題。一旦它累積了至少一天的歷史資料，我們就會把它現在的回應速度與它在同一量測點的平常速度相比較，當它明顯慢於平常時通知您——使用的是該監控項目發生事件時會用的同一組管道。速度恢復正常後，我們也會告訴您。所有方案都提供此功能。

這不是事件。沒有任何東西停機，所以它不計入可用率、不會出現在狀態頁上，也不會升級。比平常更快永遠不會發出警示；變慢必須至少達到 100 毫秒，並且明顯超出該監控項目的正常波動；監控項目暫停、處於維護時段內或已有尚未結束的事件時，不做任何判斷。

Webhook 會以 latency_anomaly 與 latency_recovered 事件接收這些通知，並附上以毫秒計的平常回應時間與實測回應時間。

Webhook

僅限 HTTPS。每個請求都會簽章，讓您能驗證它確實來自我們。私有位址與連結本機位址在您儲存 URL 時會被拒絕，並且在警示送出時會再被拒絕一次——因為儲存當下解析到公開位址的主機名稱，之後可能解析到別處，而通過驗證的 URL 也可能以一個指向任意位置的重新導向作為回應。重新導向不會被跟隨。

值班

需要 Pro 以上方案。建立輪值、設定警示升級的步驟，未被確認的事件就會沿著這些步驟往上走。確認會停止警示升級；解決則會將它關閉。

警示升級正是個人管道值得新增的理由：第一步可以是團隊聊天，最後一步可以是某個人凌晨四點的手機。

事後檢討

所有方案皆可使用。事件解決後，任何有權解決事件的人都可以撰寫事後檢討——發生了什麼、原因為何、要做哪些改變——並隨著調查進展持續修改。每個事件一份，以 Markdown 撰寫：標題、粗體與斜體、清單、程式碼、引用和連結。HTML 會以原文顯示，絕不會被執行。

事後檢討僅限內部。它絕不會出現在狀態頁上，因為其中通常會提到人員、系統與失誤。儲存動作會記入稽核日誌，記錄的是長度而非內容。

什麼都送不出去時會怎樣

失敗的管道會把原因以服務供應商自己的說法記在它自己身上，而不是默默失敗。被拒絕的簡訊會寫明電信網路說了什麼。在被接受幾分鐘後才遭拒絕的 WhatsApp 訊息，會寫明是哪個範本、哪一種語言。

這件事比聽起來更重要。這些供應商每一家都會立刻回覆「已接受」，再把真正的結果留到稍後回報——所以若不去讀那份回報，管道看起來是已驗證的，訊息看起來是已送出的，而任何人聽到的第一個消息，會是一次沒有人被告知的停機。