Uptimepage

uptimepage

正常运行时间监控、状态页和 on-call。开源，免费起步。5 分钟即可上线。

从多个区域监控 HTTP、TCP、ICMP ping、cron-job 心跳、DNS、TLS 证书和 域名到期时间，以及脚本化的浏览器登录流程——然后将绿色和红色状态转化为精美的 公开状态页，供客户订阅，并通过轮值和升级策略通知值班人员。可通过点击操作、 REST API 或 Terraform 来管理。可自托管单一二进制文件，或使用托管服务。

免费试用 →  ·  文档  ·  自托管  ·  Terraform  ·  MCP

快速开始

使用托管服务，无需安装：

1. 使用 GitHub、Google 或电子邮件地址，在 uptimepage.dev 注册——无需信用卡。
2. 添加监控项：粘贴 URL，选择检查类型和间隔，然后保存。
3. 绑定通知渠道（Slack、电子邮件、PagerDuty 等），以便故障发生时通知你。
4. 启用公开状态页并分享链接。

更喜欢用代码？可通过 REST API、Terraform 或 MCP 管理同一账户。想自行运行？请前往自托管。

为什么选择 uptimepage

内置状态页的监控服务并不新鲜——这里的目标是提供免费、可自托管且完全以代码管理的方案：

• 免费托管套餐，无需信用卡——如果你更愿意自行运行，也可使用 AGPL 版本。
• 单一独立二进制文件——运行 docker compose up 即可上线，无需运维 Kubernetes 平台。
• 一切皆可用代码管理——REST API、限定范围的令牌、官方 Terraform 提供程序，以及可供大模型查询的 MCP 服务。
• 由你掌控的探针——可在用户所在的任意位置运行多区域 Agent，并使用自己的设备。
• 状态页、事件和 on-call 集于一体——组件、订阅者、on-call 轮值和升级策略，以及持续重发直至确认的多渠道通知，无需额外工具。
• 核心功能不设付费墙——检查、状态页、订阅者、API 和所有告警渠道均包含在免费套餐中。

适用对象

• 创始人 / 小型 SaaS 团队——几分钟即可拥有专业状态页，免费且无需操心自托管。
• 平台 / SRE 负责人——以代码管理监控项、多区域探针、向 on-call 渠道发送事件通知，无需使用一堆不同的供应商。
• 自托管用户——一个二进制文件加两个数据库，不受 SaaS 锁定。

实时状态

uptimepage 会监控自身。这些徽章由运行中的应用从公开状态页面提供，不依赖第三方服务，也无需定时任务更新 JSON 文件。

服务面	HTTP	DNS	TLS 证书	域名
uptimepage.dev（网站）
app.uptimepage.dev（仪表板）
mcp.uptimepage.dev（MCP）

使用 Settings → Pages → your page → Badge 中的代码片段嵌入你自己的徽章。

功能

在线服务：https://uptimepage.dev — 托管服务，免费，可使用 GitHub、Google 或电子邮件地址登录。
完整文档：https://uptimepage.dev/docs

_{监控器 — 按环境分组，可按类型、标签或所有者筛选}

tls_cert 和 domain_expiry 使用 warn_days / critical_days 阈值，并在结果载荷中提供 days_remaining 以及注册商 / 证书主题。无论套餐如何，它们的下限分别为 tls_cert 的 1 小时和 domain_expiry 的 12 小时——这些探测跟踪的是以天而非分钟为单位变化的值，而且 RDAP 会按来源地址限制请求频率。flow 会运行真实浏览器，因此只能在提供浏览器引擎的环境中执行（其区域会限制为支持 flow 的区域），并且每个套餐对 flow 监控器的数量设有上限；请将凭据存入组织密钥，并以 {{name}} 引用。每次 flow 运行都会保留，并记录每个步骤的结果和耗时；监控器页面会以独立刻度绘制每个步骤，因此即使整个流程尚未失败，也能及时发现等待时间从 200 ms 延长到 4 秒的情况。自托管安装的该上限初始值为 0；docs/monitor-types.md 介绍了如何启用。完整的载荷结构请参阅 docs/api.md。

公开状态页

二进制文件内置了面向客户的 /status 页面（HTML + JSON + RSS 2.0）。每个目标都可以通过 public_status 选择加入；页面路由不带身份验证提取器，因此无论二进制文件运行在哪里，该页面都是公开的。边缘端会按 IP 限流，进程内缓存 10 s；如果 ClickHouse 无法访问，页面也能优雅降级。操作员可以记录事件进展（PATCH /api/v1/incidents/{id}、POST /api/v1/incidents/{id}/updates），并安排维护窗口（POST /api/v1/maintenance）。访客可以订阅邮件或 webhook 更新。请参阅 docs/public-status.md。

_{公开状态页 — 按组件显示 90 天的历史记录}

通知渠道是组织级资源（Slack incoming webhook、通用 HTTP webhook、Telegram 机器人、SMS 网关，等等），通过 /api/v1/notification-channels 创建。 传输密钥会加密后静态存储，且绝不会回显。

_{告警 — Slack、PagerDuty、SMS、webhook 及另外六种渠道}

目标可在其 alerts 数组中绑定一个或多个渠道，以启用告警：

"alerts": [
  { "channel_id": "0192…", "after_failures": 3 },
  { "channel_id": "0193…", "after_failures": 6, "notify_recovery": false }
]

仅触发一次，并在恢复时通知。渠道按租户隔离——目标只能绑定所属组织拥有的渠道。完整约定请参阅 docs/api.md。

_{添加渠道 — 选择传输方式，粘贴一项凭据}

多区域

在用户所在的区域运行探测 Agent；控制平面按区域分配检查，仪表板和状态页也可按区域查看。 可在任何位置使用自己的 Agent——只需一个绑定组织的令牌。请参阅 docs/multi-region.md。

_{监控项详情 — 按区域划分的延迟}

Terraform

使用官方 Provider uptimepage/uptimepage （源代码）以代码管理目标和通知渠道：

terraform {
  required_providers {
    uptimepage = {
      source = "uptimepage/uptimepage"
    }
  }
}

provider "uptimepage" {
  token = var.uptimepage_token # or set UPTIMEPAGE_TOKEN
  org   = "your-org-slug"      # required for managed resources; or UPTIMEPAGE_ORG
  # endpoint defaults to https://app.uptimepage.dev; set it for a self-hosted instance
}

resource "uptimepage_target" "api" {
  name     = "api prod"
  interval = 60
  check = {
    type = "http"
    http = {
      url             = "https://example.com/healthz"
      expected_status = { kind = "exact", exact = 200 }
    }
  }
}

MCP 服务

MCP 服务让大模型客户端（claude.ai 连接器、Claude Desktop、IDE）通过 /mcp 上的 Streamable HTTP，回答有关某个组织的监控项的问题，并执行少量受保护的操作。提供 19 个只读工具和 19 个写入工具（每个工具均受范围控制并经过审计；客户端可显示提示词时，还需针对每项操作进行确认）。身份验证使用绑定组织的受限令牌——可手动粘贴，也可使用一键式 OAuth 2.1 连接器。默认关闭；通过 UPTIMEPAGE_MCP_ENABLED=true 启用（连接器还需启用 + MCP_OAUTH_ENABLED）。请参阅 docs/mcp.md。

自托管

Docker（推荐）

只需三步。不需要 Rust 工具链，也无需编译。

1. 启动

docker compose up -d

拉取 ghcr.io/uptimepage/uptimepage:latest 并启动 Postgres 18、ClickHouse 26.3 和监控服务。两个数据库都会在启动时自行执行迁移，因此无需进行任何配置连接。

2. 创建账户

docker compose exec uptimepage uptimepage bootstrap-owner --email [email protected]

输出一次性登录链接、完全访问权限的 API 令牌和组织标识。这些信息只会显示一次，请在关闭终端前复制保存。

3. 登录并添加监控项

打开第 2 步中的链接，即可进入 http://localhost:8080 上的仪表板，并添加第一个监控项。

停止服务：运行 docker compose down；如需同时删除数据，则运行 docker compose down -v。

此配置没有 TLS，也没有前置身份验证，并且会发布数据库端口。适合试用，但不适合在开放互联网上安全运行。正式运行请参阅生产部署。

选项

固定版本。 设置 UPTIMEPAGE_IMAGE=ghcr.io/uptimepage/uptimepage:1.5.0，使用某个正式版本而非 latest。版本标签不带 v 前缀，但构建它们所基于的 git 标签带有该前缀。

主机使用 ARM 架构？ 正式版本标签支持 linux/amd64 和 linux/arm64。跟踪 main 上最新提交的 latest 仅支持 amd64，因此 ARM 主机请固定到某个正式版本。

ClickHouse 系统日志已关闭。 标准 ClickHouse 会保留二十多个 system.*_log 表，这些表会无限增长，并在空闲时消耗 CPU。Uptimepage 不会读取这些表，因此 config/clickhouse-quiet.xml 会将它们全部关闭；若要为调试重新启用某个表，请删除该文件中的对应行，然后运行 docker compose up -d --force-recreate clickhouse（仅重启可能会继续读取旧文件）。如果某个堆栈是在此设置加入之前启动的，则会保留旧表：先运行 docker compose up -d，让 ClickHouse 使用此设置重启，然后使用 SELECT name, formatReadableSize(total_bytes) FROM system.tables WHERE database = 'system' AND name LIKE '%\_log%' 列出这些表，并使用 DROP TABLE system.<name> 逐个删除。

之后再登录。 引导链接只能使用一次。如需重复登录并邀请团队，请配置 GitHub、GitLab、Google 或 Microsoft OAuth，或者配置用于发送 magic link 的电子邮件服务提供商（在 config/default.toml 中设置 [auth.github]、[auth.gitlab]、[auth.google]、[auth.microsoft]、[email]，或设置对应的环境变量）。请参阅 docs/authentication.md。

要将其打包到应用商店？ 第 2 步需要终端。改为设置 UPTIMEPAGE_BOOTSTRAP__EMAIL，首次启动时会创建该邮箱对应的所有者并记录登录链接，无需使用 shell。请参阅首次启动时创建所有者。

curl -X POST http://127.0.0.1:8080/api/v1/targets \
  -H 'authorization: Bearer <token>' \
  -H 'x-uptimepage-org: <org-slug>' \
  -H 'content-type: application/json' \
  -d '{
    "name": "example",
    "check": {
      "type": "http",
      "url": "https://example.com/",
      "method": "GET",
      "timeout": 10000,
      "follow_redirects": false,
      "max_redirects": 0,
      "expected_status": { "kind": "exact", "value": 200 },
      "headers": {},
      "verify_tls": true
    },
    "interval": 180,
    "enabled": true,
    "tags": []
  }'

curl -H 'authorization: Bearer <token>' -H 'x-uptimepage-org: <org-slug>' \
  http://127.0.0.1:8080/api/v1/targets/<id>/uptime
curl http://127.0.0.1:9090/metrics

生产环境部署

任何可从互联网访问的部署都应运行此堆栈，而不是上面的堆栈。此堆栈添加了带自动 TLS 的 Caddy 边缘服务、仅限内部访问的 Postgres 和 ClickHouse、按 IP 限速，以及蓝绿重启。运维主机由应用自身的登录机制保护，不使用边缘凭证。它会拉取同一个已发布镜像。设置操作指南见 deployment/README.md，架构说明见 docs/deployment.md。

Kubernetes

kubectl create namespace uptimepage
kubectl -n uptimepage create secret generic uptimepage \
  --from-literal=fingerprint-salt="$(openssl rand -base64 32)" \
  --from-literal=credentials-kek-base64="$(openssl rand -base64 32)" \
  --from-literal=postgres-url='postgres://uptimepage:[email protected]:5432/uptimepage?sslmode=require' \
  --from-literal=clickhouse-password='pw'

helm install uptimepage oci://ghcr.io/uptimepage/charts/uptimepage \
  --namespace uptimepage \
  --set domain=status.example.com \
  --set clickhouse.url=https://ch.internal:8443 \
  --set secrets.existingSecret=uptimepage \
  --set postgresql.existingSecret=uptimepage \
  --set clickhouse.existingSecret=uptimepage

请自行准备 Postgres 18 和 ClickHouse；此 Helm chart 不包含它们。另一个 chart uptimepage-agent 可在另一个区域或私有网络中单独运行探测器，并连接到此服务或托管服务。详情见 docs/kubernetes.md 和 charts/。

从源代码构建

已发布的镜像支持 linux/amd64。如果你使用 ARM 主机（Apple silicon、Ampere），或需要修改代码，请从此检出版本构建：

docker compose -f docker-compose.yml -f compose.build.yml up -d --build

堆栈相同，Docker（推荐）中的三个步骤也相同，只有镜像来源不同。请注意，本地构建会占用该镜像标签；若要恢复使用已发布的镜像，请运行 docker compose pull。

不使用 Docker 运行

cargo build --release
./target/release/uptimepage

需要 Postgres 和 ClickHouse 可通过 config/default.toml 中的 URL 访问，并且指纹盐不能为空（应用在未设置该值时会拒绝启动）：

export UPTIMEPAGE_AUTH__FINGERPRINT_SALT=$(openssl rand -base64 32)

要在不重建容器的情况下连接到 compose 堆栈运行：

docker compose up -d postgres clickhouse
cargo run --release

文档

托管版：https://uptimepage.dev/docs

源文件位于 docs/ 下，也可直接在 GitHub 上阅读：

Web UI

单个二进制文件同时提供 /api/v1/* JSON 接口和位于 / 的服务器渲染 HTML UI——使用 Askama 编译时模板、HTMX 实现局部替换和 JSON 表单（不使用 SPA 框架）、Tailwind CSS 4，以及延迟加载的 ECharts。所有 UI 修改操作都会调用现有的 /api/v1/* 端点，因此 API 始终是唯一可信数据源。技术栈、路由、添加页面指南和 UI 测试见 docs/development.md。

法律声明

相关政策由实例运营者负责。将 [legal] 中的 URL 指向你自己的条款、隐私政策及其他政策：应用会链接你设置的每项政策，在注册时展示条款和隐私政策，并在新账户中记录其版本；留空的项目则不会显示链接。详见 docs/configuration.md。 GDPR 自助服务（数据导出、账户删除、账户恢复）位于 /settings/account。

许可证

uptimepage 根据 AGPL-3.0 许可。实际影响请参阅 LICENSING.md。名称和徽标均为商标；在运行公共服务或分支版本前，请参阅 TRADEMARKS.md。

如需贡献，请参阅 CONTRIBUTING.md。 如需披露安全问题，请参阅 SECURITY.md。