Uptimepage

uptimepage

稼働状況の監視、ステータスページ、オンコール対応。オープンソースで、無料で始められます。5 分で利用開始。

複数のリージョンから、HTTP、TCP、ICMP ping、cron ジョブのハートビート、DNS、TLS 証明書と ドメインの有効期限に加え、ブラウザーでのスクリプト化されたログインフローも監視できます。さらに、 稼働状況を洗練された公開ステータスページに反映し、顧客が登録できるようにして、オンコールの担当者に ローテーションとエスカレーションポリシーを通じて通知できます。クリック操作、REST API、Terraform で管理できます。単一バイナリをセルフホストするか、ホステッドサービスをご利用ください。

無料で試す →  ·  ドキュメント  ·  セルフホスト  ·  Terraform  ·  MCP

クイックスタート

ホステッドサービスならインストール不要です。

1. uptimepage.dev で GitHub、Google、またはメールアドレスを使って登録します。カードは不要です。
2. モニターを追加します。URL を貼り付け、チェックの種類と間隔を選んで保存します。
3. 通知チャネル（Slack、メール、PagerDuty、…）を設定して、障害が発生したら通知されるようにします。
4. 公開ステータスページを有効にして、リンクを共有します。

コードで管理しますか？同じアカウントをREST API、Terraform、またはMCPで操作できます。自分で運用しますか？セルフホストをご覧ください。

uptimepage を選ぶ理由

ステータスページを内蔵した監視ツールは珍しくありません。uptimepage が目指すのは、 無料で、セルフホスト可能で、すべてをコードとして管理できることです。

• 無料のホステッドプラン、カード不要 — 自分で運用したい場合は AGPL で利用できます。
• 自己完結型の単一バイナリ — docker compose up を実行するだけですぐに利用でき、運用する Kubernetes プラットフォームは必要ありません。
• すべてをコードで管理 — REST API、スコープ付きトークン、公式 Terraform プロバイダー、そして LLM から問い合わせできる MCP サーバーを提供します。
• プローブは自分で運用 — ユーザーがいる場所ならどこでも、自分のサーバーで複数リージョンのエージェントを実行できます。
• ステータスページ、インシデント、オンコール対応を一元化 — コンポーネント、登録者、オンコールローテーションとエスカレーション、確認されるまで繰り返し通知する複数チャネルのページングを、別のツールを使わずに利用できます。
• コア機能に有料制限なし — チェック、ステータスページ、登録者、API、すべてのアラートチャネルを無料プランで利用できます。

対象ユーザー

• 創業者／小規模 SaaS — 数分でプロフェッショナルなステータスページを利用開始。無料で、セルフホストの手間もありません。
• プラットフォーム／SRE リーダー — ベンダーの乱立を避けながら、コードで管理するモニター、複数リージョンのプローブ、オンコールチャネルへのインシデント通知を実現できます。
• セルフホストを好む方 — 単一バイナリと 2 つのデータベースで利用でき、SaaS にロックインされません。

ライブステータス

uptimepage は自身を監視しています。これらのバッジは稼働中のアプリから公開ステータスページ経由で配信されます。サードパーティのサービスも、JSON ファイルを更新する cron ジョブも必要ありません。

対象	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 秒間キャッシュされます。また、ClickHouse に接続できない場合も適切に動作します。オペレーターはインシデントの経過を記録し（PATCH /api/v1/incidents/{id}、POST /api/v1/incidents/{id}/updates）、メンテナンス時間を予定できます（POST /api/v1/maintenance）。訪問者はメールまたは Webhook による更新通知を購読できます。docs/public-status.md を参照してください。

_{公開ステータスページ — コンポーネントごとの過去90日間の履歴}

通知チャネルは組織ごとのリソースです（Slack の受信 Webhook、汎用 HTTP Webhook、Telegram ボット、SMS ゲートウェイなど）。/api/v1/notification-channels を使って作成します。 通信に使うシークレットは保存時に暗号化され、応答で返されることはありません。

_{アラート — Slack、PagerDuty、SMS、Webhook、その他 6 種類}

ターゲットは、alerts 配列に 1 つ以上のチャネルを指定することで、通知を受け取るよう設定できます。

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

初回発報と復旧の通知に対応しています。チャネルはテナントごとに分離されており、ターゲットが指定できるのは、自身の組織が所有するチャネルだけです。詳細はdocs/api.mdをご覧ください。

_{チャネルの追加 — 通信方式を選び、認証情報を 1 つ入力します}

マルチリージョン

ユーザーが利用するリージョンでプローブエージェントを実行できます。コントロールプレーンがリージョンごとにチェックを割り当て、ダッシュボードとステータスページをリージョンごとに表示できます。任意の場所に独自のエージェントを導入できます。組織ごとのトークンを使う単一のバイナリです。詳細はdocs/multi-region.mdをご覧ください。

_{モニターの詳細 — リージョン別のレイテンシー}

Terraform

公式プロバイダー 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 サーバーを使うと、LLM クライアント（claude.ai コネクター、Claude Desktop、IDE）が、組織のモニターについて質問に答えたり、制限付きの操作を実行したりできます。/mcp で Streamable HTTP を使用します。読み取り専用ツールが 19 個、書き込みツールが 19 個あります（各ツールはスコープで制限され、監査されます。また、クライアントがプロンプトを表示できる場合は、操作ごとに確認を求めます）。認証には組織に紐付いたスコープ付きトークンを使用します。手動で貼り付けるか、ワンクリックの OAuth 2.1 コネクターを使用してください。デフォルトでは無効です。UPTIMEPAGE_MCP_ENABLED=true で有効にできます（コネクターには + MCP_OAUTH_ENABLED も必要です）。詳細はdocs/mcp.mdをご覧ください。

セルフホスト

Docker（推奨）

3 ステップで完了します。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]

1 回限りのサインインリンク、フルアクセスの 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 は、無制限に増え続け、アイドル時にも CPU を使用する 24 個ほどの system.*_log テーブルを保持します。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、またはマジックリンク用のメールプロバイダーを設定してください（config/default.toml の [auth.github]、[auth.gitlab]、[auth.google]、[auth.microsoft]、[email]、または対応する環境変数）。docs/authentication.md を参照してください。

アプリストア向けにパッケージ化しますか？ 手順 2 ではターミナルが必要です。代わりに UPTIMEPAGE_BOOTSTRAP__EMAIL を設定すると、初回起動時にその所有者を登録し、サインインリンクをログに記録するため、シェルは不要です。初回起動時の所有者を参照してください。

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 はご自身で用意してください。チャートには含まれていません。別のチャート 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（推奨）と同じスタック、同じ 3 つの手順ですが、イメージの取得元だけが異なります。ローカルビルドがそのイメージタグを占有するため、公開イメージに戻したいときは docker compose pull を実行してください。

Docker を使わずに実行する

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

config/default.toml の URL からアクセスできる Postgres と ClickHouse、および空ではないフィンガープリントソルトが必要です（アプリはソルトがないと起動しません）。

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 の両方を提供します。UI には askama のコンパイル時テンプレート、部分更新と JSON フォーム用の HTMX（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 をご覧ください。