心跳是 Uptime Kuma 监控系统的核心数据记录。它们代表了被监控资源的个体状态检查，并为计算正常运行时间、可视化服务健康状况以及触发通知奠定了基础。本页面将解释心跳在整个系统中是如何生成、存储和可视化的。
每次 Uptime Kuma 检查被监控服务的状态时，都会创建一个心跳。每个心跳都包含以下信息：
心跳作为所有监控器的历史记录，是正常运行时间计算、状态页面和通知触发的基础。
来源
来源
心跳记录包含以下关键信息：
| 字段 | 类型 | 描述 |
|---|---|---|
| id | 整型 | 心跳的唯一标识符 |
| monitor_id | 整型 | 指向此心跳所属监控器的引用 |
| time | 日期时间 (DateTime) | 执行检查时的 ISO 时间戳 |
| status | 整型 | 状态代码：0 (DOWN)，1 (UP)，2 (PENDING)，3 (MAINTENANCE) |
| ping | 整型 | 响应时间（毫秒）（如果适用） |
| msg | 字符串 | 错误消息或附加信息 |
| downCount | 整型 | 连续宕机状态的次数 |
来源
Uptime Kuma 在内部使用数字状态代码来表示监控器的状态。
这些状态代码在代码库中被定义为常量，并在整个系统中用于表示监控器的状态。
来源
心跳的生成方式取决于监控器的类型。
对于基于 HTTP 的监控器，心跳包括：
心跳状态由以下因素决定：
对于基于网络的监控器，心跳包括：
Push 监控器的工作方式是反向的。
对于专用监控器（DNS、Docker、游戏服务器、数据库等），心跳包含特定于监控器的信息，但遵循相同的基本结构。
来源
下图说明了监控器检查是如何调度的和处理的。
来源
心跳存储在数据库的 heartbeat 表中。该模式包括：
数据库模式的设计旨在高效处理随时间累积的海量心跳记录。
来源
Uptime Kuma 通过多种方式可视化心跳：
HeartbeatBar 组件显示一系列小块，代表监控器的近期心跳。这提供了近期监控器状态的快速可视化概览。
心跳条中的每个块都用颜色编码来表示状态（UP、DOWN、PENDING、MAINTENANCE），并在鼠标悬停时显示时间戳。
来源
下图显示了心跳数据如何流经系统。
来源
Uptime Kuma 提供了几种与心跳交互的方式：
心跳是正常运行时间计算的基础。系统通过分析心跳历史记录来计算不同时间段（24 小时、7 天、30 天等）的正常运行时间百分比。
来源
Push 监控器与其他监控器类型的运作方式不同。
此方法对于监控以下场景很有用：
来源
考虑到对于间隔较短的监控器，心跳可能会迅速累积，Uptime Kuma 实施了多项优化措施：
来源
以下组件显示或与心跳交互：
来源