服務突然打不開時，最容易做的事是重啟、重部署，甚至直接想換平台。
但 Zeabur 這類部署平台有一個很現實的特性：你一重啟，某些現場資訊可能就消失了。根據 Zeabur Logging & Streaming 文件，Runtime Logs 只在服務執行期間可用；服務重啟或重新部署後，前一個 instance 的 runtime logs 不會繼續留在 dashboard 裡。
所以我會把處理順序改成：先判斷問題在哪一層，再保存線索，最後才決定重啟、修設定或遷移。
這篇整理的是我會用的 Zeabur 服務異常排查流程。它不是要說 Zeabur 一定有問題，也不是把所有狀況都推給自己的程式。真正要避免的是：還沒看 logs、還沒確認 status、還沒分清楚是 service 還是 server，就先做破壞性操作。
先把問題分成三層
排查前，我會先把問題拆成三層：平台、server、service。
| 層級 | 可能現象 | 先看哪裡 |
|---|---|---|
| 平台層 | 多個 region、dashboard 或 gateway 都出問題 | Zeabur status page、官方公告 |
| Server 層 | 同一台 server 上多個 service 一起異常，K3s 狀態不正常 | Server 頁面、K3s 狀態、主機資源 |
| Service 層 | 只有單一 API、worker、web 或 database 異常 | Build Logs、Runtime Logs、環境變數、PORT |
這個分層很重要。因為不同層級的處理方式完全不同：
- 平台層有 incident 時，亂重裝 service 只會增加變數。
- Server 層 OOM 時，重啟單一 service 可能沒用。
- Service 層設定錯誤時，換 VPS 也只是把同一個錯誤搬到別處。
截至我查詢的 2026 年 7 月 8 日，Zeabur Status 顯示「All services are online」。這只能代表當下沒有公開標示的全域事故，不代表你的 project、server 或單一 service 沒有問題。
重啟前先做三個檢查
如果服務還能進 dashboard，我不會第一個動作就按 Restart。我的順序會是：
- 看 status page。
- 比對自訂網域與
.zeabur.app網域。 - 保存 Runtime Logs。
1. 看 status page，不要只看自己的服務
如果 status page 已經有 incident，先不要急著重部署。這時候要確認的是影響範圍：只有 dashboard 慢、還是 gateway、registry、server 管理也受影響。
如果 status page 正常，再回到自己的 project 查。
2. 比對自訂網域與 .zeabur.app
同一個服務，我會同時測：
- 自訂網域，例如
https://api.example.com - Zeabur 產生的
.zeabur.appdomain
如果 .zeabur.app 正常但自訂網域異常，方向會偏向 DNS、憑證或 domain binding。
如果兩個都壞，再看 service 本身、server 狀態或 upstream dependency。
3. 保存 Runtime Logs，再做下一步
Zeabur 把 logs 分成兩種：
| Log 類型 | 用途 | 常見問題 |
|---|---|---|
| Build Logs | 看部署過程，例如安裝依賴、編譯、build script | dependency、build command、Dockerfile、package manager |
| Runtime Logs | 看服務啟動後的 stdout / stderr | 環境變數、PORT、資料庫連線、OOM、程式例外 |
官方文件提到 log viewer 支援關鍵字搜尋，可以用來找錯誤訊息、stack trace、request ID 或 log level。實務上我會先搜這幾類字：
ERRORWARNExceptiontimeoutECONNREFUSEDENOMEMout of memorylistenPORTdatabaseredis如果服務還在跑，先把可疑段落複製下來，或至少截圖、記錄時間點。尤其是 runtime 問題，不要先按 restart。
我會記這些資訊：
| 欄位 | 例子 |
|---|---|
| 發生時間 | 2026-07-07 18:30 Asia/Taipei |
| 影響範圍 | API 500、前台可開、worker 卡住 |
| 最近變更 | 剛改環境變數、剛更新 image、剛改 domain |
| 第一個錯誤 | DATABASE_URL is missing、listen EADDRINUSE、OOMKilled |
| 已嘗試動作 | 尚未重啟、已重部署、已回滾 |
這些資訊後面不只自己看得到，也會影響你跟 Zeabur Support 溝通的效率。
重啟前先保存 Logs如果你還沒保存 Runtime Logs，不要急著重啟。Zeabur 文件說明，服務重啟或重新部署後，前一個 instance 的 runtime logs 不會繼續留在 dashboard 裡。
從 Logs 判斷下一步
Zeabur FAQ 對部署失敗列了幾個常見原因：build error、缺少環境變數、port 設定錯誤、記憶體不足，並建議到 Dashboard 查看 service logs。
我會先用 logs 判斷問題落在哪裡。
Build 失敗：先修部署
如果 Build Logs 裡已經有錯，例如依賴安裝失敗、build command 錯、Dockerfile 階段錯，那就先修部署流程，不要看 runtime。
這類問題通常會在 deploy 階段就停住，不會真的跑到應用程式啟動。
Build 成功但服務打不開：看 Runtime
常見狀況是：
- build 階段不需要資料庫，runtime 才需要。
- build 階段用的是預設值，runtime 環境變數缺漏。
- image 成功拉下來，但 entrypoint 啟動失敗。
- app 有啟動，但沒有 listen 在平台指定的 port。
Build logs 回答的是「有沒有成功產生部署版本」，Runtime Logs 回答的是「服務啟動後有沒有活著」。
三個常見原因：環境變數、PORT、OOM
如果 Build 成功，但服務仍然打不開，我會先查這三類。
環境變數要看值，也要看作用範圍
Zeabur 的環境變數可以在服務間 expose，也可以引用其他變數。這很方便，但也代表排查時要確認三件事：
- 變數是否存在。
- 變數值是否是你以為的值。
- 變數是否在正確 service 可讀到。
例如 API 服務需要 DATABASE_URL，但資料庫服務只 expose 了 POSTGRES_CONNECTION_STRING，或 worker 和 API 使用不同變數名稱，就會出現「Dashboard 看起來有設定，但程式讀不到」的狀況。
如果剛改過變數，建議記錄修改時間，並確認服務是否已用新變數重新啟動。
PORT 問題不要猜
Zeabur 的 Public Networking 文件提到，Git service 不建議在程式裡硬寫 port，應使用 $PORT 環境變數。
Node.js 類型服務可以用這種寫法：
const port = process.env.PORT || 3000;
app.listen(port, () => { console.log(`server listening on ${port}`);});如果程式硬寫 3000，但平台實際要求的是另一個 port，就可能出現健康檢查失敗、服務看似啟動但外部連不到的情況。
這類問題不要靠猜，直接在 runtime log 印出實際 listen port，或確認 framework 的 Zeabur 部署文件。
OOM 要看是 service 還是 server
如果是單一 service 記憶體不足，Runtime Logs 可能會看到 out-of-memory、process killed，或服務不斷重啟。
如果是整台 server 出問題，情況會更大。Zeabur 的 Maintain Server 文件 說明，當 server OOM 時，server dashboard 的 K3s 狀態可能變紅，Kubernetes 不再正常運作，服務也會變成不可達。
這時候重啟單一服務不一定有用，因為問題不在單一 container，而是整台 server 的資源或 K3s 狀態。
Server OOM 時，我會這樣恢復
Zeabur 官方文件對 server OOM 的恢復流程有一個細節很重要：如果 K3s 已經 offline，重啟 server 時建議先取消所有服務自動啟動，避免 server 一開機又立刻被同一批服務打滿記憶體。
我會照這個順序做：
- 到 Server 頁面確認 K3s 狀態。
- 如果 K3s 為紅色或 offline，到 Settings 執行 Reboot Server。
- 在 reboot dialog 裡先取消所有服務自動啟動。
- 等 server 回到健康狀態。
- 從最基礎的服務開始逐一啟動，例如 database、redis、API、worker、web。
- 每啟動一個服務就觀察 CPU、RAM 與 logs。
如果一啟動某個 worker 就立刻 OOM，問題就比「Zeabur 壞掉」更具體：可能是 worker concurrency 太高、任務堆積、image 太肥、記憶體規格不足，或部署到同一台 server 的服務太多。
如果這種情況反覆發生，再考慮調整 server 規格、拆服務、設定資源保留，或把部分服務搬到另一台 VPS。
什麼時候重啟，什麼時候不要
我會用這張表決定下一步：
| 狀況 | 建議動作 | 原因 |
|---|---|---|
| Runtime Logs 正在輸出錯誤 | 先保存 logs，再修設定或重啟 | 重啟後前一個 instance 的 logs 可能不見 |
| Build logs 顯示缺 dependency | 修 build 設定後 redeploy | 問題在部署階段 |
| 只改環境變數後服務沒吃到 | 重新啟動該服務 | 讓 runtime 讀到新變數 |
| 單一 service OOM | 降低負載、調整設定或升級資源 | 重啟可能只會再 OOM 一次 |
| K3s 狀態異常或整台 server offline | 依 server OOM 流程 reboot | 單一 service restart 不一定碰得到問題 |
| 官方 status 有 incident | 先暫停破壞性操作 | 事故期間重裝可能讓現場更混亂 |
「重啟」是排查工具，不是證據。按下去之前，最好知道自己想驗證的是什麼。
什麼情況才該考慮遷移或分流
我不會因為單次 incident 就立刻遷移。平台、VPS、自架面板都會出問題，差別在於問題發生時你拿得到多少控制權，以及你的服務能不能承受那種恢復時間。
我會在這幾種情況考慮遷移或分流：
- 同一類 OOM 或 K3s offline 在短時間內重複發生。
- 服務需要更細的主機層監控、系統服務控制或自訂網路設定。
- 持久化資料、備份或 volume 操作已經超出 Dashboard 能安全處理的範圍。
- 你需要把正式環境與測試環境拆到不同供應商，降低單一平台風險。
- Support 需要介入，但你的服務恢復時間不能等到人工回覆。
如果要自架，可以回頭看我之前寫的 Zeabur 改方案後，重新評估 Coolify 自架部署（2026）。但 Coolify 不是免費版 Zeabur，它只是把更多控制權交還給自己，也把更多維運責任交還給自己。
如果只是想看主機資源，可以先用 btop 這類工具確認 CPU、RAM、磁碟與 process 狀態。站內也有一篇 btop / btop++：現代化的系統資源監控工具 可以對照。
聯絡 Support 前先整理這包資訊
Zeabur FAQ 提到，聯絡支援時可以提供 projectID、serviceID 或 deploymentID。我會再補幾個欄位，讓支援比較快判斷問題：
## 問題摘要- 發生時間：- 影響服務：- 使用者看到的錯誤：- 是否只有自訂網域異常：
## 近期變更- 最新 deployment：- 最新環境變數調整：- 最新 image / template 變更：
## 已查過- Zeabur status page：- Build logs：- Runtime logs：- Server / K3s 狀態：- 是否重啟過：
## ID- projectID：- serviceID：- deploymentID：這份資訊也適合自己留存。下次同樣問題發生時，不需要從記憶裡重建整個事故。
我的處理順序
整理一下，我會把 Zeabur 服務異常的處理順序固定成這樣：
- 看 status page，確認是不是平台層 incident。
- 比對自訂網域與
.zeabur.app，先排除 domain 問題。 - 保存 Runtime Logs，再決定要不要重啟。
- 從 Build Logs / Runtime Logs 判斷問題階段。
- 依序檢查環境變數、PORT、資料庫連線與 OOM。
- 如果是 Server OOM，先避免所有服務一起自動啟動。
- 同類問題反覆發生時，再考慮拆服務、升級規格或遷移。
這樣做的好處是，每一步都有明確目的。就算最後真的要搬到 Coolify、VPS 或其他平台，也會知道自己是在解決哪一層問題，而不是因為一次服務異常就整包重來。
常見問題
Q: Zeabur 服務異常時，可以先重啟看看嗎？
A: 可以，但不要把它當第一步。先保存 Runtime Logs、記錄發生時間與最近變更，因為 Zeabur 文件提到服務重啟或重新部署後，前一個 instance 的 runtime logs 不會繼續在 dashboard 裡可用。
Q: status page 顯示正常，就代表一定是我的程式問題嗎？
A: 不一定。status page 正常只代表沒有公開標示的全域事故。問題仍可能出在你的 project、server、service、domain、環境變數、port、資源限制或持久化資料。排查時要先縮小影響範圍。
Q: 如果 K3s 變紅，應該直接重裝 server 嗎？
A: 先不要。Zeabur 文件針對 server OOM 建議透過 Reboot Server 恢復，並在重啟時取消所有服務自動啟動，等 server 健康後再逐一啟動服務。重裝是更後面的選項，做之前要先確認資料備份與服務遷移路徑。
參考資料：
Zeabur Docs：Logging & Streaming
回報錯字、失效連結，或告訴我你想看的延伸主題。