API monitoring and health checks
An API can answer quickly and still be broken. Send the request your clients send and check what comes back.
What each check does
- Sends GET, HEAD, POST, PUT, PATCH, DELETE or OPTIONS to the endpoint, with your headers.
- Sends a request body of up to 16 KB with the methods that take one.
- Checks the status code and, if you want, that the response contains or does not contain a piece of text.
When it alerts
- A timeout, a connection error or a status other than the one you expect.
- A response that lacks the text it should contain, or contains the text it should not, such as "error".
https://api.example.com/healthGood to know
- Put tokens in headers such as Authorization; members other than owners and admins see them masked.
- The keyword search reads the first 1 MB of the response.
- Set a slow threshold between 100 ms and 60 s to catch an API that is getting slower before it fails.
On every monitor
- Alerts by email, Slack, Discord, Teams, Telegram, PagerDuty, webhooks, Lark, ntfy and the mobile app.
- Recovery thresholds, so an incident closes only after the service has answered several times in a row.
- Dependencies: a monitor that depends on another stays quiet while that one is down.
- Maintenance windows, incident history and public status pages built from the same monitors.
Try it on the Free plan
The Free plan includes 3 monitors checked every 5 minutes, with every alert channel. No card needed.
Questions
Should I monitor a health endpoint or a real endpoint?
Both if you can. A health endpoint that checks the database and other dependencies tells you why something failed; a real read-only endpoint, with a keyword check on its JSON, tells you what your clients see.
Can I monitor an endpoint that needs authentication?
Yes. Add the header your API expects, such as Authorization: Bearer with a token made for monitoring, ideally one that can only read.
Will a POST check create data?
It sends the request every time, so it does whatever your API does with it. Point write checks at an endpoint that is safe to call repeatedly, or at a test account.
API 监控与健康检查
API 可能响应很快，却已经坏了。发送和你的客户端相同的请求，检查返回的内容。
每次检查做什么
- 向端点发送 GET、HEAD、POST、PUT、PATCH、DELETE 或 OPTIONS 请求，并带上你的请求头。
- 对可以带请求体的方法，发送最多 16 KB 的请求体。
- 检查状态码，也可以检查响应中是否包含或不包含某段文本。
什么时候告警
- 超时、连接错误，或状态码不是预期值。
- 响应缺少应包含的文本，或出现了不该出现的文本，例如 “error”。
https://api.example.com/health使用说明
- 把令牌放在 Authorization 等请求头中；除所有者和管理员外，其他成员看到的是遮盖后的值。
- 关键词检查会读取响应的前 1 MB。
- 把变慢阈值设在 100 毫秒到 60 秒之间，在 API 彻底失败之前发现它在变慢。
所有监控通用
- 通过邮件、Slack、Discord、Teams、Telegram、PagerDuty、Webhook、飞书、ntfy 和手机 App 告警。
- 可设置恢复阈值，服务连续多次正常后故障才结束。
- 依赖关系：依赖另一个监控的监控，在被依赖方宕机期间不会告警。
- 维护窗口、故障历史，以及由同一组监控生成的公开状态页。
常见问题
该监控健康检查端点，还是真实端点？
可以的话两个都监控。会检查数据库等依赖的健康端点能告诉你哪里出了问题；真实的只读端点加上对 JSON 的关键词检查，能告诉你客户端看到的是什么。
需要认证的端点能监控吗？
可以。添加 API 需要的请求头，例如带上专门用于监控的令牌的 Authorization: Bearer，最好是只读权限的令牌。
POST 检查会产生数据吗？
每次检查都会真的发送请求，API 收到后会照常处理。请把写操作的检查指向可以重复调用的端点，或使用测试账号。