Runner 任务突然中断，缩容日志却把它判成 busy: false

自托管 Runner 已经开始执行任务，几分钟后任务突然失败或取消。缩容日志显示 REST API 返回 "busy": false，自动化随即注销 Runner 并终止云实例。若 Runner 自己的日志仍在续租当前任务，应先把实例、任务和缩容决策对齐，不能凭一次 idle 查询确认它可以删除。

这类排查适用于自行管理 Runner 实例生命周期的环境。任务取消的文字本身不能证明云实例被误删，也不能证明所有版本的 busy 状态都有相同问题。

用同一个实例还原时间线

至少保留任务 ID、Runner ID、云实例 ID，以及带时区的时间。对照任务开始、Runner 续租与结束、缩容查询、删除调用和云平台终止事件，确认它们指向同一台机器、同一次任务。

REST 查询的准确路径、发出时间和响应内容也要保留。组织级与仓库级查询、旧缓存、复用名称或映射到另一实例，都会妨碍判断。记录必要字段即可，认证头和令牌不进入排查资料。

同时保存 Runner 的 _diag/Runner_*.log、任务步骤日志和缩容程序的执行记录。实例已终止后，本地磁盘上的唯一日志可能消失，不能等下一次事故再去那台机器采集。

如果云平台审计明确显示是自己的缩容身份发起终止，且当时该实例持有未完成任务，才能把这个删除决策纳入故障链。还应区分实例故障、人工取消、Spot 回收、资源不足和业务步骤本身失败，避免把所有 canceled 都归给自动缩容。

出现冲突证据时，先暂停受影响的删除路径

已经确认“正在执行”与“缩容判断空闲”相冲突时，按现有运维流程暂停受影响实例池的破坏性空闲删除，保留必要容量与监控。不要继续硬删正在续租的实例，也不要把创建 Runner 或其他正常任务一起无差别关闭。

注销 API 返回成功并不证明删除时没有任务。自动化需要有完整的生命周期决策和保护，而不是把成功 DELETE 当作空闲确认。临时延长轮询间隔也只是减少查询机会，不是根因修复或完成证明。

保存实际 Runner、缩容组件和配置版本，再检查已发布修复是否覆盖本地现象。不能因为有一个更新版本，就宣布状态一致性问题已解决；没有确认的修复边界时应保留未知，并用实际日志验证候选方案。

单任务 Runner 仍需要安全的实例回收

GitHub 推荐自动扩缩容使用 ephemeral Runner。它只接受一个任务，处理后由服务注销，可以减少复用实例接收后续任务时的生命周期冲突。

但 ephemeral 不会自动替外部缩容器保护正在执行的第一次任务，也不会自动清理云虚拟机。自己的程序若仍根据错误的空闲判断提前终止实例，单任务模式并没有让这个删除动作变安全。

评估迁移时同时设计任务完成、注销、实例清理、失败处理与外部日志保存。已有 Kubernetes 环境可评估 ARC；自定义基础设施可评估 Runner Scale Set Client。两者都需要结合当前容量、成本和网络边界实施，不是随手切换一个布尔值就完成整套回收。

已有 Terraform 模块的 enable_ephemeral_runners 也只是配置入口。先核对所用模块版本和真实 Runner 注册模式，确认配置生效，再验证实例第一次任务和收尾行为；不要直接对正式池执行一份未经检查的新舰队配置。

缺少收尾记录是线索，还要核实终止原因

任务有开始记录却没有完成记录、post 步骤全被跳过，值得追查机器或进程是否中途消失。但日志未上传、其他异常和任务形态也会影响这些记录，不能把某种 post-step 组合当成唯一的物理终止证明。

修复后的受控验证应覆盖新 Runner 执行任务、完整结束、正确回收，以及复用模式保留时的连续任务。核对每次回收对应的任务已完成，没有未解释的中途终止，日志能在实例删除后继续追溯。恢复缩容前保留原配置和回退入口；一次任务运行成功，不足以证明生命周期判断已可靠。