现在搭个服务状态页面，动不动就要配PostgreSQL，配Redis，再搞个K8s集群。

前两天在GitHub上翻到一个叫BetterStatusPage的开源项目，部署方式就一行docker compose up -d。整个应用跑在单个Node.js 22进程上，数据库用的SQLite，不需要额外装任何数据库服务器、缓存或者消息队列。

这个项目目前还在MVP阶段，但核心功能已经能用了。最让我意外的是它内置了备份和离线恢复——万一哪天服务器挂了，拿之前的备份文件直接恢复，不至于从头配起。

监控能查什么

监控类型覆盖得比较全。HTTP和HTTPS检查是基本功，能校验返回的状态码、响应时间，还能在响应正文里搜关键词。身份认证方面支持基础认证、OAuth2和CAS三种方式，对内部系统监控比较实用。

网络层面的检查也没落下：ICMP ping用来测连通性，TCP端口检查可以确认服务端口是否在监听。DNS监控覆盖了A、AAAA、MX、CNAME和TXT五种记录类型，域名解析出问题能第一时间发现。

数据库层面目前只支持SQL Server的测试查询，对于用微软技术栈的团队算是个加分项。还有一个被动Webhook监控功能，cron任务跑完或者外部服务要上报状态时，调个接口就行。

告警能发到哪儿

通知渠道覆盖了五种：邮件、通用Webhook、Discord、Slack和Microsoft Teams。告警发出去如果失败了，系统会自动重试，管理员也可以在后台面板里手动检查失败记录、手动重发。

这个重试机制比很多商业SaaS做得都好——至少你不用半夜被吵醒之后，还得去排查"为什么告警没收到"这种二次伤害的问题。

恢复通知也支持，服务恢复正常了会自动发一条消息，不用手动更新状态。

状态页和事件管理

公开状态页的编辑方式是拖拽网格布局。你可以往上拖监控卡片、服务分组、Markdown文本块，还有一个事件时间线组件，全程不需要写CSS。自定义品牌标识和深色模式也做了，多语言支持也在功能列表里。

事件管理这边的功能设计得比较细。创建事件时可以标记严重等级、关联受影响的监控项，还能添加事件更新的时间线记录。定时维护窗口也支持——你设定下周三凌晨维护，系统会自动在这个时间段抑制告警，不会给用户发一堆假警报。

监控依赖关系这个功能挺少见的。比如你有台服务器宕机了，上面跑的三个服务都会报故障。配好依赖关系后，系统知道根因是服务器挂了，只发一条告警，不会同时弹三条通知把你淹掉。

实时更新走的是Server-Sent Events协议，状态页上监控项的状态变化会实时推送到浏览器。运行时间历史记录也保留着，想看过去七天某个接口的可用率，直接查就行。

用户角色、审计日志这些企业级功能也都做了，审计日志能记录字段级别的变更——谁在什么时候把监控间隔从30秒改成10秒了，一查就知道。

安全方面做了个AES-256-GCM加密的凭据保险箱。数据库连接字符串、API令牌这些东西不需要明文写在监控配置里，加密存进去就行。

为什么要做这个项目

作者的想法很直接：他要的不只是一个简单的uptime检测器，但也不想为了搭状态页专门维护一套基础设施。很多小团队、家庭实验室或者个人项目，配数据库服务器、缓存、消息队列再加好几个容器的运维成本，比状态页本身的业务价值还高。

BetterStatusPage的目标体验就是一条命令启动，一个进程一个端口跑完全部功能。不需要先装PostgreSQL、装Redis、配集群网络，省下来的时间精力可以干点别的。

目前作者在找人帮忙测试部署、在家庭实验室或者小规模生产环境里跑跑看，报bug、审安全设计、提缺失的监控类型或者集成需求——特别是安装升级体验、界面配置易用性、通知可靠性这些方面，还有"你觉得自己不会认真用它之前，它还需要什么功能"这类直击要害的反馈。

MIT协议开源，GitHub地址在BElluu/BetterStatusPage，有兴趣可以直接拉下来跑一趟。