GitHub Actions macOS Runner 排隊太久怎麼辦？2026 擴容判斷
macOS 工作長時間停在 Queued，或還沒開始任何 step 就被取消。
最快的判斷：先看工作有沒有進入執行步驟，再查並發、標籤與 Runner 在線狀態；確認是自有 Mac 執行環境不足，才評估增加自託管 Runner。若問題在 GitHub 端調度，增加 Mac 不會修好服務故障。
適合正在排查 iOS 建置或發布工作佇列的獨立開發者。
也適合受 macOS CI 影響合併、發布節奏的小型團隊。
維護自託管 Runner 的開發者，可用本文核對接單狀態與路由條件。
先保留證據：不要只憑整次執行的總耗時判斷排隊。保存工作時間線、取消狀態與日誌，再分辨它停在派發前、啟動階段，還是已經開始建置。
GitHub Actions macOS Runner 排隊：先分清派發與建置
「排隊久」和「建置慢」是兩種不同故障。工作若已進入編譯或測試步驟，才應查 Xcode、依賴解析、測試或資源使用；若沒有任何 step 開始，則要先查工作是否取得 Runner。
GitHub 託管 Runner 由 GitHub 提供執行環境；自託管 Runner 則需要團隊維護機器及接單狀態。兩者的派發路徑不同，排查時先確認工作流程使用哪一類 Runner。GitHub 對託管 Runner 的說明與執行限制，可分別參閱託管 Runner 的運作方式及官方限制文件。
| 工作狀態與線索 | 較可能的問題範圍 | 優先核對項目 |
|---|---|---|
| 尚無 step 開始，工作仍在佇列 | Runner 尚未接單、並發規則等待，或託管環境暫時無法派發 | Runner 類型、時間線、並發設定、GitHub Status |
| 尚無 step 開始，之後被取消或失敗 | 派發或初始化異常；不等於程式碼編譯失敗 | 工作日誌、取消原因、Runner 取得或啟動訊息 |
| 已有 step 開始，之後失敗 | 建置或測試階段的問題 | 失敗步驟、Xcode 與依賴設定、測試輸出 |
| 自託管 Runner 沒接到工作 | Runner 離線、忙碌，或標籤與 group 不匹配 | Runner 狀態、工作流程標籤、服務日誌 |
用命令列查看工作資料時，可以先查狀態、結論和工作列表：
gh run view "$RUN_ID" --json status,conclusion,jobs
輸出示意：
{
"status": "queued",
"conclusion": null,
"jobs": []
}
這類輸出只協助定位狀態，不代表已找出根因。應再回到該次執行的時間線與日誌，核對是否有 Runner 指派或初始化訊息。GitHub 的工作流程疑難排解文件也可用來對照失敗階段。
Hosted Runner 與自託管 Runner：查不同證據
若只有 macOS 工作停在派發前，先看工作使用的 Runner 類型，再查看 GitHub Status 是否有相關服務狀態。官方文件指出，macOS Runner 未及時取得處理時可能被丟棄，因此不應把一次未啟動就取消的工作當成建置失敗；應保存日誌，並依狀態更新決定是否重跑。GitHub Status可協助核對服務公告。
2026 年 11 月 3 日至 9 日的 GitHub Community 討論中，有使用者回報 macOS arm64 工作遇到容量提示或在 step 開始前失敗。這是社群個案，不是 GitHub 對普遍故障、確定根因或修復結果的確認；可把它當成比對線索，不應據此推論所有帳戶都受影響。相關討論
| 排查目標 | GitHub 託管 Runner | 自託管 Mac Runner |
|---|---|---|
| 派發與可用性 | 查看工作狀態、日誌及 GitHub Status | 查看 Runner 是否在線、是否已被占用 |
| 路由條件 | 核對 workflow 要求的執行環境 | 核對標籤及 Runner group 是否吻合 |
| 啟動異常 | 留存 Runner 取得或容量相關提示 | 查看 Runner 服務與主機端日誌 |
| 能否由團隊直接修復 | 平台側問題通常只能等狀態更新或重新驗證 | 可先修正離線、標籤、服務或接單設定 |
自託管 Runner 若沒有接到工作，不能只因工作排隊就歸因於 GitHub 託管容量。先從 Runner 狀態檢查在線與忙碌情況，再比對 workflow 的標籤和 group。GitHub 提供自託管 Runner 的監控與疑難排解指引，以及自託管 Runner 的使用說明。
工作流程並發與標籤：排隊可能來自專案設定
macOS 工作增加時，先看 workflow 是否把不同執行放進同一個 concurrency group。GitHub 的並發規則會影響同一組工作執行的等待與取消行為；這是專案工作流程的排程規則，不能靠多加一台 Mac 消除。官方 concurrency 說明說明了設定方式與限制。
| 工作流程線索 | 可能的本地排程原因 | 可採取的檢查或調整 |
|---|---|---|
| 同一事件反覆觸發相同建置 | 重複觸發或不必要的工作執行 | 檢查觸發條件，確認是否需要每次都跑完整 macOS 工作 |
| 多個工作共用 concurrency group | 工作互相等待，較新的待處理執行可能取代舊執行 | 確認 group 範圍，避免不相關工作共用一組 |
| 非 macOS 檢查也等待 Mac 工作 | 工作依賴順序過於保守 | 讓不依賴 macOS 的檢查先行或平行執行 |
| 只有自託管工作排隊 | 標籤或 Runner group 路由不符，也可能是 Runner 忙碌 | 對照 workflow 與 Runner 設定，確認有符合條件的在線 Runner |
如果測試 workflow 已設定並發控制，先確認取消舊執行是否安全。對發布、簽名或產物上傳工作，不宜為了讓畫面上的佇列變短而直接啟用取消進行中的工作。合併重複驗證、讓純靜態檢查先跑，可能減少專案自身造成的等待；但這些調整不保證能排除 GitHub 託管環境的容量或服務問題。
等待、調整或擴充：按故障分支決定
| 證據指向 | 優先處理 | 不應預設的結論 |
|---|---|---|
| GitHub Status 有相關服務異常，或託管 Runner 日誌提示無法派發 | 保存狀態與日誌，依官方更新等待或稍後重試 | 不要假設多一台自託管 Mac 能修復 GitHub 調度 |
| 工作未進入 step，且使用自託管 Runner | 查在線狀態、占用情況、標籤及 group | 不要把標籤不符誤判成託管 Runner 容量問題 |
| 工作因 concurrency 規則等待或被取代 | 調整 group、觸發條件或工作依賴 | 不要把工作流程佇列問題當成硬體不足 |
| 多個 iOS 工作持續需要 Mac，現有環境接單不足 | 評估額外自託管 Mac 作為並行備選 | 不要把新增執行環境視為平台故障保證解法 |
評估備選 Mac Runner 時，先用實際 iOS 專案做驗收，不要只確認主機可連線。驗收可依序進行：
- 確認派發條件：核對 workflow 使用的標籤與 Runner group，並確認 Runner 狀態在線。
- 提交代表性工作：選擇團隊平常會執行的建置或測試工作，不以空白測試工作代替。
- 確認工具鏈：從工作日誌核對選到的 Xcode 與專案要求一致。
- 檢查簽名與權限：確認工作需要的憑證可用，並檢查秘密資料是否只在預期工作中提供。
- 驗收建置結果：確認目標建置或測試完成，並留存產物、日誌與失敗步驟。
- 再做佇列判斷：記錄工作是否接單及在哪個階段等待，再決定備選環境是否真正解決團隊的 Mac 接單不足。
每次驗收應留下工作連結、Runner 狀態、工具鏈選擇與產物結果。若工作已接單但在 Xcode 或測試步驟失敗，應轉向建置排錯；若始終沒有接單，則回到標籤、group、Runner 狀態和派發證據。本文沒有可核實的本站實測資料，因此不對 SFTPMAC 的配置、接單能力或建置速度作出預設承諾。若正比較遠端 Mac 是否適合作為備用執行環境，可先瀏覽SFTPMAC 的服務選項，再依團隊的工作流程自行驗收。
常見問題
排隊期間要不要一直重新執行？
先確認工作是否仍停在派發前，並查看 GitHub Status 與日誌。若有服務狀態更新，依更新決定等待或重新執行；若工作是被 concurrency 規則取代，反覆重跑可能只會再次進入相同隊列。保留原始執行記錄，才能比較重跑是否改變 Runner 指派或工作階段。
如何判斷自託管 Runner 接到工作後才出問題？
若工作時間線顯示已分配 Runner，或日誌已開始出現 Runner 執行資訊，應檢查主機端服務日誌與實際失敗步驟。若沒有接單跡象，先核對 Runner 在線狀態、標籤和 group。把「沒有匹配到執行環境」與「已接單但啟動異常」分開，才能選對修復方向。
哪些工作適合先移出 macOS 佇列？
不依賴 Xcode 或 macOS 的檢查，可評估提前執行，例如不需要 Apple 工具鏈的程式碼檢查。是否能平行化，取決於專案依賴與發布流程；先確認它們不需要前置建置產物，也不會繞過必要的測試閘門。這種編排能處理工作流程自身的等待，不能承諾消除平台容量限制。
什麼情況才值得增加 Mac 執行環境？
當多個實際 iOS 工作持續需要 Mac、Runner 路由已核對，且等待來自可用執行環境不足，才評估增加自託管 Mac Runner。若 GitHub Status 顯示服務端問題，或工作沒有匹配到正確標籤，應先處理對應原因。新增主機也要計入維護、工具鏈更新與憑證管理責任。
最後更新於 2026 年 11 月 11 日；資料核實自 GitHub Actions 限制、託管 Runner 說明、自託管 Runner 監控文件、GitHub Status 及上述 Community 個案討論。
若排查後確認真正的瓶頸是團隊缺少可持續接收 iOS 工作的 Mac 環境，可以把遠端 Mac 納入候選；它不會取代 GitHub 端的派發服務，也不一定適合需要長期固定負載或實體介面的團隊。相較於只靠 GitHub 託管 Runner，額外 Mac 執行環境仍需驗證接單路由、工具鏈與產物；自購設備則有前期採購及自行維護的負擔。若只是階段性建置、測試備援或先驗證工作流程，可先參考 SFTPMAC 的方案資訊，再用自己的 iOS 專案驗收是否符合需求。