前言
前面都在把 API 本身「做好」：欄位有沒有對、時間有沒有時區、錯誤有沒有統一、查不到有沒有說明。到今天開始可以看「實際使用起來穩不穩」，這就需要有幾個指標可以每天記、之後畫圖。
一、為什麼要做指標
因為體感會騙人。你覺得好像今天都不能查，可能只是早上 7:30 不行；你覺得還不錯啊，可能只是你沒遇到尖峰。用指標把每次呼叫記下來，報告就講得清楚。
二、最少要有的 6 個指標
1.請求總次數（totalRequests）
這個時段總共打了幾次 API，可以看出有沒有人在用、尖峰在哪。
2.成功率（successRate）
成功次數 ÷ 總次數。成功是指有回 200 而且資料格式正常，這是「穩不穩」最直接的數字。
3.平均回應時間／延遲（avgLatencyMs）
一次請求從送出到回來花了多久。都成功但很慢，也是一種要改善的狀況。
4.429 次數（tooManyRequestsCount）
被對方說「你查太多了」的次數。這個高，就要回去調 Day 12、Day 17 的查詢頻率或快取時間。
5.資料新鮮度（dataFreshnessSeconds）
現在顯示的資料跟 updateTime 差了幾秒。公車這個主題最在意這個，要在畫面上寫出來。
6.無資料次數（noDataCount）
來源有回，但說「現在沒有到站資訊」的次數。這不一定是錯誤，但太多會影響使用者感受。
三、怎麼記下來
現在可以先用試算表或手動紀錄：每打一次 API，就記一行 timestamp、apiName（routes/stops/eta）、status（200/429/503）、latencyMs、isFromCache、isNoData。之後要做儀表板時就可以直接用這幾欄。
四、要怎麼看這些數字
•成功率低：先看是不是來源打不到，不要立刻改程式。
•429 多：表示查太頻，應該拉長快取或改成「系統先抓、大家共用」。
•回應時間高但成功率 100%：表示「慢」不是「壞」，可以在畫面標「資料更新於 …」。
•noData 多：可能是那幾站班次少，也可能是來源當天不穩，可以改文案。
五、小結
•本專題會記錄請求次數、成功率、回應時間、限流次數、資料新鮮度與無資料次數。
•資料新鮮度是本專題最重要的指標，要在畫面上顯示更新時間。
•無資料要跟「來源打不到」分開算，報告才看得出來是哪一種問題。
•後續的排程與儀表板都會用這六個欄位當基本欄位。