Uptime monitoring for DevOps teams
A monitoring tool for operations should page for real outages, stay quiet for noise, and be scriptable. These are the features that map to that, and what you run yourself when you self-host.
What to monitor
Pages for outages, not for one bad route
Check HTTP and TCP monitors from several regions. The run fails when most answering regions fail, or when the number you set fail. A probe that cannot be reached is left out of the vote instead of counted as a failure, and if no probe answers the check falls back to the default location. The incident names the regions that failed.
One root cause, one page
Make dependent monitors point at the monitor they rely on, for example every service behind a gateway. While the parent is down, the children keep recording but open no incident and send no alert. A failure within ten minutes of a resolution reopens the incident and sends a short "down again" alert instead of a full new page.
An alert that does not get lost
Send the first alert to Slack and PagerDuty. Set repeat reminders at an interval you choose, and add escalation levels that notify further channels when the incident is still unacknowledged after a number of minutes. Acknowledging the incident, including from the iOS app, stops the repeats.
Cron, queues and internal services
Heartbeat monitors cover scheduled jobs. For services on a private network, self-host OpenUptime and set ALLOW_PRIVATE_TARGETS=true; by default monitors that point at private or loopback addresses are refused, which protects a shared instance. Do this only when you trust every account on it.
Monitoring as code, and agents
Create, change and pause monitors through the REST API with an API key, export a project's monitors as JSON for review or backup, and import them elsewhere. The MCP server gives agents such as Claude or Cursor the same reach after an OAuth approval, limited to the workspaces and projects you choose.
Status page
Keep an internal or public status page for the services other teams and customers depend on. Group monitors by component, post updates as an incident moves through investigating, identified, monitoring and resolved, and let subscribers follow by email or RSS.
Alert routing
Alert channels are Slack, Lark / Feishu, Telegram, PagerDuty, webhooks and email. A webhook receives a JSON POST, so it can feed a chat bot or your own tooling. Delivery results are logged per channel so you can see which alert went out and which failed.
Limits to know about
- No on-call rotation schedules or phone-call paging; escalation is by channel and minutes unacknowledged.
- Database monitors check reachability only.
- No TLS certificate expiry or ICMP ping monitors.
- Multi-region covers HTTP and TCP monitors only.
Questions
How does OpenUptime avoid alerting for a single region failing?
With several regions, a run fails only when most of the regions that answered failed, or when the number you set in the monitor settings fail. A tie counts as up.
Can I monitor services on a private network?
On a self-hosted instance, yes, after the operator sets ALLOW_PRIVATE_TARGETS=true. The hosted service and Cloudflare Workers cannot reach private ranges.
Is there a Terraform provider?
No. Use the REST API or the JSON import and export to keep monitors in version control and apply them with a script.
Set it up in OpenUptime
Start on the hosted service, or run it yourself. The source is on GitHub under the MIT license.
DevOps 团队的可用性监控
运维团队用的监控工具应当在真正故障时告警、在噪音面前保持安静，并且可以脚本化。下面是与此对应的功能，以及自托管时需要自己运行的部分。
监控什么
为故障告警，而不是为一条糟糕的线路告警
让 HTTP 和 TCP 监控从多个区域检测。多数应答区域失败，或达到你设定的失败数量，本次检测才判定失败。无法连接的探针不参与投票，也不算作失败；如果没有任何探针应答，检测会回退到默认位置。事件中会写明哪些区域失败。
一个根因，一次告警
让依赖型监控指向它所依赖的监控项，例如网关背后的每个服务。父监控故障期间，子监控仍会记录，但不创建事件也不发送告警。恢复后十分钟内再次失败，会重新打开该事件并发送简短的“再次故障”告警，而不是新建事件。
不会被漏掉的告警
第一条告警发送到 Slack 和 PagerDuty。可按所选间隔设置重复提醒，并添加升级层级：事件在若干分钟后仍未确认时，通知更多渠道。确认事件（包括在 iOS 应用里确认）即可停止重复。
定时任务、队列与内部服务
心跳监控覆盖定时任务。对于私有网络里的服务，请自托管 OpenUptime 并设置 ALLOW_PRIVATE_TARGETS=true；默认情况下，指向私有或回环地址的监控项会被拒绝，以保护共享实例。只有当你信任实例上的所有账号时才这样做。
监控即代码，以及 Agent
通过带 API 密钥的 REST API 创建、修改和暂停监控项，将项目的监控项导出为 JSON 用于评审或备份，并可导入到别处。MCP 服务在 OAuth 授权后让 Claude、Cursor 等 Agent 拥有同样的能力，范围限于你选定的工作区和项目。
状态页
为其他团队和客户所依赖的服务维护内部或公开的状态页。按组件对监控项分组，在事件经过调查中、已定位、观察中和已解决的过程中发布更新，并让订阅者通过邮件或 RSS 关注。
告警路由
告警渠道包括 Slack、飞书 / Lark、Telegram、PagerDuty、Webhook 和邮件。Webhook 会收到一个 JSON POST，可接入聊天机器人或你自己的工具。每个渠道的发送结果都会记录，方便查看哪条告警已发出、哪条失败。
需要了解的限制
- 没有值班排班表和电话告警；升级按渠道和未确认的分钟数进行。
- 数据库监控只检查连通性。
- 没有 TLS 证书到期和 ICMP ping 监控。
- 多区域检测仅适用于 HTTP 和 TCP 监控。
常见问题
OpenUptime 如何避免因单个区域故障而告警？
使用多个区域时，只有多数应答区域失败，或达到你在监控设置里指定的失败数量，本次检测才判定失败。票数相同时视为正常。
能监控私有网络中的服务吗？
在自托管实例上可以，前提是运维设置 ALLOW_PRIVATE_TARGETS=true。托管服务和 Cloudflare Workers 无法访问私有网段。
有 Terraform provider 吗？
没有。请使用 REST API 或 JSON 导入导出，把监控项纳入版本控制，并用脚本应用。