一個網站重新上線，另一個網站切換卡在半路
這天延續前一天發現的斷線問題，開始把離線的網站一個一個救回來，第一個真正救回來的是A 站。過程並不順利：網域憑證原本卡在審核中的狀態，查出來是DNS少了一筆驗證用的紀錄；補上之後等了超過一小時，原本那張憑證還是沒有轉成有效，只好另外申請一張新的憑證，這次同樣的網域驗證幾秒內就通過。接著要恢復以前的評論、收藏、通知等功能時，才發現現有的雲端服務其實只做出諮詢與床位分析兩項，其餘功能包含2,828個機構頁面都要用到的評論功能全部沒接上；如果直接對外開放，網站上還會出現「已認證家屬」這類其實不成立的顯示。因此我們先把靜態頁面裡對應的文字與連結整個拿掉，原本22,066個檔案、29,398筆資料原封不動保留。
功能補上以後，健康檢查卻連續404，一度懷疑是容器沒啟動或設定沒接好。後來查出來是雲端平台本身保留了一批以「z」結尾的網址路徑，像是/healthz，會直接在服務前面回應404，跟程式碼、資料庫或先前處理過的權限問題都沒有關係。把健康檢查路徑從/healthz改成/health之後，馬上恢復正常。xmy在確認沒問題後直接指示公開，A 站在這天完成正式的公開切換：憑證生效、DNS指到新的雲端位置，7,367個檔案裡有7,328個實際被覆蓋更新，評論功能先開放但保持空白，認領功能先換成一頁維護中的說明，暫時不放進sitemap。
B 站是下一個排上復站清單的網站——同一批離線站裡，B 站是少數不帶資料庫或會員功能的純靜態網站，理論上最好處理，實際做起來還是一波三折。第一次建置時發現有一支沒被引用的檔案裡還留著舊版的功能字串，判定不夠乾淨，整批作廢重來；重建後197個檔案逐一核對通過、176頁sitemap也對得上。換憑證時，驗證流程一度在DNS設定完成前就先判定失敗，後來換Google自己重試才轉為有效。真正要把網址路由接上時，第一次測試就發現網站顯示的是一個空白的預設畫面而不是正確內容，176項驗收裡只測了2項，而且2項都失敗，其餘174項還沒開始跑就先整個停下來，直到這天結束都還沒有重新排定，網域也還沒有真正切過去。
另一頭，C 站準備上線的100家新公司資料頁，也在反覆修正裡前進。第一次建置時，雲端建置環境缺了一個套件，直接建置失敗；修好後的第二次，負責覆核的代理人抓出一個寫入順序的風險——如果建置環境中途不穩定，有可能在還沒完成核對前就搶先把沒有核准的內容寫進正式位置——因此暫停，直到把「先核對、才寫入」的順序鎖死才放行；第三次成功，把100家新公司頁與170個相關檔案、合計270個異動送進一個暫存區，但還沒有正式接上公開網站，等待下一步核准。
C 站另外還有一個規模更大的專案，要把整個網站從靜態頁面全面改成資料庫驅動的動態版本；這天完成了一次建置測試——新版容器成功啟動，動態公司頁與網址地圖都正常產出——但當天只做到建置測試，還沒有部署上線。
前一天測試出來的68篇合格草稿，這天正式對外發布，分散在GCS靜態頁面、OpenAI Sites與自己的雲端服務三種管道（64、2、2），沒有用到Vercel；這套排程之後就固定在台北時間每天凌晨自動執行。
這天也試著清一次磁碟空間：找出8個內容重複的暫存套件資料夾，理論上刪除後能騰出不少空間，實際刪完卻只多出一點點可用容量，離原本設定的門檻還有一段落差，判斷可能是磁碟區塊被其他複本共用，或有其他工作同時在寫入資料，沒有再往下清，留到之後再查。
這天沒有再出現新的網站斷線，大多是在收拾前一天發現的爛攤子。救回一個網站往往牽涉憑證、DNS、程式相容性好幾層，任一層卡住就要整個停下來重新排隊，而不是硬著頭皮往下做。