10 月 15 日早高峰，DeepSeek 崩了！
8 点 11 分起，网页端和 App 陆续弹出「服务器暂时不可用」或「服务器繁忙，请稍后重试」。API 同步中断，话题很快冲上热搜。
从故障发生到恢复，官方状态页记下了 4 小时 52 分。
中断 4 小时 52 分，13 点 04 分恢复官方状态页写得很清楚。故障从 8 点 11 分开始，13 点 04 分标记解决，中间隔了 4 小时 52 分。
过程分三步。9 点 06 分定位到原因，12 点 49 分实施修复并转入监控，13 点 04 分服务恢复。最早一条更新停在 8 点 11 分，写的是正在排查问题。
受影响的有三块，DeepSeek V4 Pro API 服务，DeepSeek V4.1 Flash API 服务，还有对话服务。
图1、官方状态页的本次事件记录
补偿来了，7 天消耗以赠金全额返还当天傍晚，DeepSeek 开放平台发布《服务恢复及补偿通知》。
先致歉，再给方案。通知说，对于此次故障带来的不便与困扰，深表歉意。
补偿口径不绕弯。按用户账号 7 日内，也就是 10 月 8 日至 10 月 14 日的消耗金额，以赠金形式全额返还。
赠金自动到账，之后的 API 计费扣款先从赠金账户扣除。
图2、官方补偿通知全文
官方回应，排查并剥离单点依赖通知里还交代了后续动作。
官方说，已第一时间启动针对服务稳定性的全面排查和彻底整改，全面梳理并剥离单点依赖，坚决杜绝同类问题再次发生。
不过，这次故障的具体原因，官方没有披露。
把状态页往回翻，这不是第一次状态页的历史记录里，10 月记了 5 起，9 月记了 8 起。
10 月 12 日一次性能下降 15 分钟，一次部分中断 11 分钟。10 月 8 日性能下降 3 分钟，10 月 2 日性能下降 1 小时。
9 月 15 日那次部分中断持续了 3 小时，9 月 24 日一次性能下降挂了 48 分钟，其余大多是几分钟到几十分钟的降速。
把区间拉到近三个月，状态页给出的可用性是，V4 Pro API 服务 99.74%，V4.1 Flash API 服务 99.46%。
图3、官方状态页的近期事件记录
补偿补的是 7 天消耗，中断却落在早高峰，对把任务托管给 API 的团队，稳定性这笔账，和价格一样得提前算。