99.743% · 30 天
111 分钟计划外停机时间，具体原因逐条列于下方；计划内维护不计入统计，另行列出。
此刻
十项指标，每项都有独立衡量方式
「Operational」这个词本身说明不了什么。每一行都附有实际检测得到的数值，因此一个技术上在线但速度缓慢的组件，无法躲在一个绿点后面。
所有系统运行正常
最近检测于 03:29 UTC · 6 天前 内无计划外事件 · 过去 90 天在线时间 99.894%
虚拟服务器
运行正常
34 台虚拟化主机正在上报
独立服务器
运行正常
全部机箱正常上报
网络——运营商 A
运行正常
BGP 已建立 · 抖动 0.3 ms
网络——运营商 B
运行正常
BGP 已建立 · 抖动 0.6 ms
DDoS 过滤
运行正常
待命中 · 无主动缓解
客户面板
运行正常
83 毫秒中位响应时间
公开 API
运行正常
54 毫秒中位响应时间
开通
运行正常
59 秒获得 root 权限的中位数
付款
运行正常
全部 8 个网络确认中
支持中心
运行正常
首次回复中位数为 7 分钟
中位数取自过去五分钟内、来自三个非我方网络探测点的数据。一旦某个组件的中位数超过其正常水平的两倍，就会被标记为「降级」——我们宁可多报，也不愿把糟糕的十分钟粉饰成绿色。
计算得出，而非自我宣称
三个时间窗口，以及每个窗口背后的具体分钟数
单独一个百分比可以随意选取。这里的每个数字，都是对其下方事件列表做的算术——更改列表，百分比就会随之变化，这才是唯一值得公布的版本。
99.894% · 90 天
137 分钟计划外停机时间，具体原因逐条列于下方；计划内维护不计入统计，另行列出。
99.954% · 365 天
241 分钟计划外停机时间，具体原因逐条列于下方；计划内维护不计入统计，另行列出。
所发生的一切
事故历史记录，包括由我们造成的事故
只包含计划内维护的历史记录算不上历史记录。每条记录都会说明故障内容、持续时长，以及后续做出的改动，以避免同样的问题再次发生。
-
2026-08-22 · 6 天前
至伊斯坦布尔的丢包率部分 · 111 分钟
运营商 A 上游的一处误将我们的一个前缀列入黑洞路由。经过 51 分钟排查后已从该运营商撤销；一小时后完全恢复可达。期间前往其他所有城市的流量均未受影响。
-
2026-07-08 · 2 个月前
开通队列停滞部分 · 26 分钟
新订单被排队等待，而非直接开始构建。现有服务器不受影响。原因是镜像主机的存储池已满，该主机现已调整为在 70% 时告警，而不是 95%。
-
2026-05-05 · 4 个月前
API 限流器过于激进部分 · 47 分钟
一次收紧的限流拒绝了三位正在搭建机群的客户的合法突发流量。一小时内即回滚，并改为按令牌计算的突发额度。
-
2026-03-09 · 6 个月前
面板响应缓慢，服务器不受影响部分 · 38 分钟
一次迁移导致账单表缺失索引，面板运行缓慢。虚拟化层、网络与 API 均未受影响。所有提交工单的账户都获得了补偿，无需自证受到影响。
-
2025-12-28 · 8 个月前
已启用过滤，340 Gbps部分 · 19 分钟
针对某客户地址的流量型攻击已在上游被吸收。过滤在持续期间增加了约 2 ms 延迟。没有任何黑洞路由，也没有要求任何人离开。
早于此期限的记录会保留，并在申请时提供，而不会无限期公开——保留三年历史的页面，没有人会读到底。任何计划外事件的补偿都会按照在线时间 SLA自动发放，无需您申请。
本页面是如何生成的
四项让这些数字值得一读的决定
其中每一项都会让我们的数据显得比另一种做法略逊一筹，这恰恰说明它们不是为了粉饰数据而选用的。
从我们自身网络之外进行探测
来自其他服务商的三台机器，分别位于法兰克福、阿姆斯特丹和纽约。若状态页的探测点位于其监控的数据中心内部，那么它在故障期间也会显示为绿色。
组件先降级，再下线
比平时慢，也是我们会公开的一种状态，而不会被我们含糊地归为「运行正常」。下方大多数条目是性能下降而非彻底中断，这才是诚实的历史记录该有的样子。
在线时间是计算得出的，而非凭空宣称
上述百分比均来自下方列出的事故分钟数。修改历史记录，百分比就会随之变化；我们没有另一套可以悄悄美化的数字。
本页面并非托管于 Chișinău
它特意运行在别处，这样即便大楼断电，也不会连带带走本该告诉您这一点的页面。