可用率 = account_health 里 source ∈ (relay, probe) 的成功次数 ÷ 观测次数， 只统计选定的时间窗。没有任何观测的账号显示「—」，不是 100% —— 「没量过」跟「量到全通」是两件事。
「探测」发的是一个真实但最小的上游请求（列模型），不建对话、不吃消息额度； free 类型走浏览器池，探一次等于开一个匿名对话，后端会直接回「不支持探测」。
额度 / 速率水位来自 /api/admin/accounts/limits（lib/account-limits.js）。 三个上限都是真的闸门：取号的四层（用户指派 / 对话亲和 / 团队池 / 全域池）全部过闸， 超额的账号会被硬过滤掉，不是只画成一条进度条。
三态语义：留空 = 不限（预设，也是目前绝大多数账号的状态）、 0 = 明确停用、> 0 = 上限。 没有上限的那一条不画水位，只印实际观测到的用量 —— 画一条 0% 会被读成「用了 0%」，可是「没设上限」根本没有水位这回事。
唯一的例外是并发上限（accounts.max_concurrency）： 它留空 = 沿用全域 account_concurrency，不是无限。 那道全域闸门一直在挡，所以留空的账号照样画得出水位（分母取后端一起回的 effective）。把它画成「无上限」会让人以为给某一个账号填值是在收紧， 其实那才是唯一真的改变了行为的动作。
额度的单位是 USD（usage_log.cost）而不是 token：一个池子里同时有 gpt-4o、grok 与 chatgpt-web，把它们的 token 加起来得到的数字既不是钱也不是量。 要按 token 管的是 tpm_limit，那本来就是速率。
防降智那一栏是「上游实际服务的模型」对上「请求的模型」，三态分开算： model_verified（比对过、一致）/ model_mismatches（比对过、不一致）/ model_unverifiable（这条路拿不到模型身份，或请求的是 auto）。 三栏全是 NULL 时显示「尚未观测」而不是「0 次不一致」 —— 拿一个从来没查过的东西冒充查过了，比不显示更糟。 free 类型走浏览器池只回文字块，结构上就验不了。
封号风险（lib/ban-risk.js）收的是四类目前一笔都没有落库的原始观测， 不是把 consecutive_failures 乘一个系数换个颜色 —— 那个数字这一页早就画着，而且它刻意不含 429 与 CF 403， 可是「被边缘层挡下来」恰恰是封号风险最强的讯号之一。四类是： 拒绝形状（把 last_error 的原文真的分类： 403+HTML 挑战页 / 403 Unusual activity ... from your device / 401 token_invalidated 三者在库里长得一样，处理方式完全相反； 429 与 5xx 权重 0）、 刷新健康（换 token 的成败，以及这次换到的寿命是不是腰斩）、 延迟基线（拿账号自己的历史中位数当对照组，跨账号比只会量到谁挂在哪条代理）、 上游状态（RT 刷新被 401/403 拒 → status = banned）。
四条讯号不是每种账号都观测得到：apikey 永远不刷新 token、 free 连状态码都拿不到。观测不到的记「不适用」， 一条都没观测到的账号分数是「—」而不是 0 分 —— 一个评不了的账号显示成最安全，跟把「无法验证」画成「已验证 ✓」是同一个错误。 每一列都附「观测 n/m」，因为「四条都量过、都干净」跟「只量到一条」不是同一件事。

跨用户的密钥治理：额度消耗、日调用限额、IP 与模型白名单、启停、轮替与删除。
清单由 /api/admin/users + 逐个用户的 /api/admin/users/:id/keys 拼出来 —— 后端没有全站密钥列表端点，所以这里看到的用户集合与「用户」页完全相同。
白名单留空 = 不限；allow_ips 一旦有值就代表清单外的来源一律拒绝， 要解除强制就把它清空（后端没有「配置保留但停用」这个状态）。

只有 status = active 而且此刻落在时间窗内的公告，才会出现在用户端。 开始 / 结束留空 = 该侧不限；结束早于开始会被后端拒绝（不会静默夹回）。
「已读」数来自 announcement_reads（每人一笔，幂等）；已读率的分母是 /api/admin/users 回的用户总数 —— 后端没有「订阅者 / 推送触达」这类计数，这里不编。

比例一律是整数百分比：20 = 20%，合法范围 0–100（超范围后端会拒绝，不会静默夹回）。
用户的「专属比例」留空 = 跟随全局，跟设成 0% 是两件不同的事。
累计分润 是历史累计入账，待转出 是还没转进余额的部分； 两者相减就是「已转出」—— 这一页的占比条画的就是这个，没有第三个来源。

风控规则命中 → 按每个通道的订阅条件异步分发。条件三选：级别门槛（事件级别 ≥ 通道门槛）、 动作白名单、规则类型白名单 —— 三个都留空 = 全收。
Webhook 带 签名头（HMAC-SHA256）；密钥永远不会从任何 GET 回传， 编辑时留空 = 保留原密钥，要清空得明确送一个空字串。
防轰炸聚合：同一个（通道 × 规则）在窗口内只送第一条，后续命中并进那一条并累加 ×N。 0 = 关闭聚合。

按模型聚合 usage_log：调用量、错误率、Token 流向、均延迟、涉及用户数与账号数。
异常判定口径：调用 ≥ — 且错误率 ≥ —% → 「错误率偏高」； 均延迟 ≥ — ms → 「延迟偏高」；model_pricing 里没有这个模型 → 「未定价」 （那代表这些调用一律吃 getModelPrice() 的保底单价，是真的漏收）。
缓存命中率只拿「上游真的回报过 cached_tokens」的那几笔算： 分母是那几笔的输入 Token，一笔都没回报过就显示「未回报」而不是 0% —— ChatGPT 网页那条路根本拿不到 usage，记成 0 会把命中率稀释成一个看起来很低的假数字。
风控命中只数 risk_events.model 非空的事件。这一栏是后来才补的， 所以时间窗若早于开始记录的时刻，栏里会标出「自 … 起」； 记录到了但本来就与模型无关的事件（例如登录端点的 IP 封锁）单独列在下面的未归属里， 不并进任何一个模型的数字。

三源合一：usage_log（调用）·risk_events（风控）·llm_audit_log（预审）。 支持 key:value 精准检索与自由词模糊匹配，两者可以混用。
某一源没有的字段会把那一源整个排除，不是「这个条件对它不生效、其余照捞」—— 否则 ip:1.2.3.4 这种收窄的手势反而会让结果变多。哪个源被排掉、被哪个字段排掉，都印在下面。
分页跨三张表是精确的：排序键 (时间 ↓, 来源, id ↓) 是全序，所以第 N 页与第 N+1 页不会重叠、也不会跳过任何一列； 总数是三张表各自 COUNT(*) 的和，没有「每源先取 N 笔再合并」的天花板。
req: 单独出现时走精确关联（billing.getTrace），不扫三张表 —— 三张表都有 request_id，所以那是按 id 对上的，不是「同用户 + 同模型 + ±5 秒」凑出来的。 只贴后几码时会落回子串检索。
旧列的 request_id 是 NULL：那些请求发生在开始记录 ID 之前（或本来就没有请求情境）。 所以「查无此 ID」与「那一笔查不回来」会分开讲，还会告诉你有几笔是这种。
这一页不取代「使用记录」（那是 usage_log 的计费视图，有费用明细、栏位开关与 CSV 汇出）、 「风控」（规则 CRUD）、「审计日志」（查的是 audit_log，谁改了什么，根本不是这三源之一） 与「模型审计」（按模型聚合，不是列级检索）。这一页是横着问三张表的入口，那几页是单源深挖的去处。

三个渠道：inapp 站内信、email 邮件、webhook。 外部渠道带去重窗口（存 DB 不是内存，重启不会补发）。
订阅明细来自 /api/admin/notify（全站横切的只读聚合）。 Webhook 的签名密钥只回 has_secret，明文不出现在任何回应里。
这一页只读订阅、不代用户改订阅：通知订阅是用户自己的设定， 管理端能治理的是报表排程（下面那张表）。

上半部的经营分析来自 /api/admin/billing?days=N（与「计费管理」同源同口径）； 下半部的排程与产出来自 /api/admin/reports。
排程的拥有者决定报表寄去哪：报表最终经他的通知订阅送出，所以建立时选的是「谁的报表」， 不是「寄给谁的邮箱」。scope=platform 的平台经营报表只有管理员订得了。
同一条排程、同一个统计周期只会产出一份（UNIQUE(schedule_id, period_start)）—— 停机三天后重启补的是一笔，不是三笔。