您好，帮您查了一下，先说结论：
您的 OpenClaw 服务现在是 RUNNING 状态，对外也访问得到（刚测了 openclaw-ai8367.zeabur.app 返回 200）。从昨晚 20:48 UTC 服务器重启之后 Pod 就稳定跑了 7 个多小时，「SUSPENDED 起不来」的状态已经自己恢复了。请您重新打开 Dashboard 刷一下应该会看到正常状态。
但是 backup 列表里那笔显示「running」的记录确实是卡住的：那是 4-29 16:23 启动那次备份，DB 里 status 一直没翻成失败，所以前端永远显示 running。这是我们后端的 status sync bug —— 当 backup 容器是被强杀（OOM）而不是正常退出时，状态没办法正确回写。这笔幽灵记录目前不影响您实际服务，我们会一起跟着 PLA-1377（前几天发现的 build 端同类 bug）处理掉。
关于这次为什么会被 Kill：这台是 2C4G 的新加坡机器，目前跑着 8 个用户服务，可用内存只剩 3Gi 左右。OpenClaw 官方推荐配置是 2C8G — 平时单跑 OpenClaw 还撑得住，但备份会瞬间打包大量数据进内存做压缩，很容易把节点压到 OOM，触发系统去杀进程救命。建议：
- 如果要继续用备份功能，强烈建议把服务器升到 8G（Servers → 选这台 → Resize），单次备份内存压力就不会再触发 OOM。
- 如果暂时不想升级，备份前先停掉一些不常用的服务释放内存再做，并且注意控制 OpenClaw 自己的工作量。
如果按上面调整后还是卡住，请您再回这条，我帮您从底层确认一下 backup 流程。
论坛