Uptime monitoring for SaaS
A SaaS product fails in more places than its home page. These are the checks that map to a typical stack, and how customers find out about an incident.
What to monitor
The API answers, and answers correctly
Point an HTTP monitor at your health endpoint, set the expected status code, and require a keyword from the response body, such as "ok". A 200 from an error page then still counts as down. Add a request header if the endpoint needs a bearer token.
Background jobs and cron
A heartbeat monitor gives each job a URL to call when it finishes. If no ping arrives within the interval plus a grace period you set, the monitor fails. This catches a job that silently stopped, which no HTTP check can see.
Databases and caches
PostgreSQL, MySQL / MariaDB and Redis monitors confirm that the server answers its handshake or PING. They send no credentials and run no queries, so they show reachability, not query health. The target must be a public address unless the operator allows private targets on a self-hosted instance.
Customers in more than one part of the world
For HTTP and TCP monitors, pick several regions. The run fails when most of the regions that answered fail, so one bad route does not open an incident, and a probe that is down is left out of the vote. Each region counts as one check. Where the probes are depends on the deployment; see the multi-region docs.
Fewer pages for the same outage
Make the monitors of services behind your API depend on the API monitor: while it is down they keep recording but open no incident and send no alert. A failure within ten minutes of recovery reopens the previous incident (and sends a short "down again" alert) instead of opening a new one.
Status page
Publish a status page with your monitors grouped by component, for example API, Dashboard and Webhooks. Customers can subscribe by email or RSS, and you post updates on an incident as it moves from investigating to resolved. The embeddable badge puts the current state on your own site.
Alert routing
Send alerts to Slack for the team and to PagerDuty for whoever is on call, and route each monitor to only the channels that need it. Set repeat reminders and an escalation level that fires when an incident stays unacknowledged.
Limits to know about
- Checks run at most once a minute.
- No synthetic browser tests for sign-in or checkout flows.
- No TLS certificate expiry warning; track renewals separately.
Questions
How do I monitor background jobs with OpenUptime?
Create a heartbeat monitor, copy its URL and call it at the end of each run. If a ping is missing after the interval and grace period, the monitor goes down and alerts.
Can customers subscribe to incident updates?
Yes. Each public status page offers email subscriptions with double opt-in and an RSS feed. Subscribers are emailed when an incident opens or resolves on a monitor shown on that page.
Can I create monitors from CI or with an AI agent?
Yes. Everything in the app is available through the REST API with an API key, and the MCP server lets agents such as Claude or Cursor create monitors and status pages after you approve access with OAuth.
Set it up in OpenUptime
Start on the hosted service, or run it yourself. The source is on GitHub under the MIT license.
SaaS 产品的可用性监控
SaaS 产品出问题的地方不止首页。下面是与典型技术栈对应的检测方式，以及客户如何得知事件。
监控什么
API 不仅有响应，而且响应正确
为健康检查接口创建 HTTP 监控，设置预期状态码，并要求响应体包含某个关键字，例如 "ok"。这样返回 200 的错误页面也会被判定为故障。如果接口需要 Bearer 令牌，可添加请求头。
后台任务与定时任务
心跳监控会为每个任务生成一个 URL，任务完成时调用它。如果在间隔加上你设置的宽限期内没有收到请求，监控就会失败。这能发现悄悄停止的任务，而 HTTP 检测看不到这一点。
数据库与缓存
PostgreSQL、MySQL / MariaDB 与 Redis 监控用于确认服务端能响应握手或 PING。它们不发送凭据、不执行查询，因此反映的是连通性，而不是查询是否健康。目标必须是公网地址，除非自托管实例的运维允许私有目标。
客户分布在多个地区
为 HTTP 和 TCP 监控选择多个区域。多数应答区域失败时本次检测才判定失败，因此某一条线路出问题不会创建事件，而自身故障的探针不参与投票。每个区域算一次检测。探针的位置取决于部署方式，详见多区域文档。
同一次故障，少一些告警
让 API 背后的各服务监控依赖于 API 监控：它故障期间，这些监控仍会记录状态，但不创建事件也不发送告警。恢复后十分钟内再次失败，会重新打开上一个事件（并发送简短的“再次故障”告警），而不是新建一个。
状态页
发布状态页，按组件对监控项分组，例如 API、控制台、Webhook。客户可通过邮件或 RSS 订阅，你可以在事件从调查中到已解决的过程中发布更新。可嵌入的徽章能把当前状态显示在你自己的网站上。
告警路由
把告警发到 Slack 通知团队，发到 PagerDuty 通知值班的人，并让每个监控项只路由到需要它的渠道。可设置重复提醒，以及事件长时间未确认时触发的升级。
需要了解的限制
- 检测最快每分钟一次。
- 不支持针对登录或结账流程的浏览器合成测试。
- 没有 TLS 证书到期预警，请另行跟踪续期。
常见问题
如何用 OpenUptime 监控后台任务？
创建心跳监控，复制它的 URL，并在每次任务结束时调用。如果超过间隔和宽限期仍未收到请求，监控会变为故障并发出告警。
客户可以订阅事件更新吗？
可以。每个公开状态页都提供双重确认的邮件订阅和 RSS 订阅。该页面上展示的监控项出现事件或事件解决时，订阅者会收到邮件。
能在 CI 中或通过 AI Agent 创建监控吗？
可以。应用中的功能都可以通过带 API 密钥的 REST API 使用，MCP 服务也允许 Claude、Cursor 等 Agent 在你通过 OAuth 授权后创建监控项和状态页。