稼働監視 & ステータスページ 2026 — Better Stack / Pingdom / Uptime Robot / Uptime Kuma / Checkly / Statuspage 徹底比較

"ダウンタイムは避けられない。本当のダウンタイムは、計測されていないダウンタイムだけだ。" — Charity Majors、Honeycomb 共同創業者、2024

稼働監視は「あなたのサービスは生きているか?」という最も基礎的な問いに答えるツールです。1998年にSiteUptimeが登場してから30年近く本質は変わっていませんが、その間に監視対象は単純なHTTP 200応答からSSL証明書の期限切れ、DNS伝播、TLDの期限切れ、APIレスポンスボディ、合成ユーザーフロー(Synthetic User Flow)、cronジョブの欠落まで爆発的に拡大しました。

2026年5月時点で稼働監視市場は4つの大きな陣営に整理できます。(1) 古参SaaS(Pingdom、Uptime Robot、Updown.io、Better Stack)、(2) APM統合型のシンセティック監視(Datadog Synthetic、New Relic Synthetics、Checkly)、(3) オープンソースのセルフホスト(Uptime Kuma、Gatus、OneUptime、Cachet)、(4) ステータスページ(Atlassian Statuspage、Instatus、Better Stack Status Pages)。本稿では各カテゴリーの代表製品、価格、機能の違い、そして韓国・日本企業の実際の運用事例まで一気にまとめます。

1. 2026年の稼働監視マップ — SaaS / OSS / APM統合 / ステータスページの4分類

稼働監視ツールは2026年時点で4つの箱に整理できます。

各カテゴリーは重なります。Better StackはSaaSでありながらステータスページとon-callも統合しており、OneUptimeはOSSでありながらSaaSも提供しステータスページも含みます。Checklyはシンセティック監視から出発しましたが、API監視とローカルPlaywright実行までカバー範囲を拡げました。

2026年最大のトレンドは 「単一製品への統合」 です。以前はPingdom(稼働)+ PagerDuty(on-call)+ Statuspage(告知)+ Datadog(メトリクス)の4つを糊付けして使っていたものを、Better StackとOneUptimeは1つのダッシュボードにまとめました。この統合パッケージがSMB市場で急速にシェアを伸ばしています。

2. Better Stack — BetterUptime+Logtail を2023年8月に統合

Better Stackは2018年スロバキアでBetterUptimeという稼働監視SaaSとしてスタートしました。2021年にLogtailというログ管理製品を別個に出した後、2023年8月に両製品を統合して Better Stack という単一ブランドへリブランドし、同年のシリーズAで1800万ドルを調達しました。2025年時点で従業員約80人、顧客数万、ARR(年間経常収益)は約2000万ドル規模です。

Better Stackのコア差別化要素は 「稼働 + ログ + 通知 + ステータスページ + on-call」 の5つを1つのダッシュボードに統合した点です。競合製品では分離されていた次の領域が結合されています。

• 稼働チェック(旧BetterUptime、Pingdomと同等)
• ログ収集とSQL検索(旧Logtail、Datadog Logsと同等)
• 通知ルーティングとスケジュール(PagerDuty Lite)
• ステータスページのホスティング(Statuspageの代替)
• インシデント管理(incident.io Lite)

価格は無料プラン(モニター10個、3分チェック)から始まり、Freelancer($29/月)**、**Small Team($99/月)、Business($299/月) と上がります。Pingdom古参プランの半額でより多くの機能を提供する点が最大の強みです。

もう一つの強みは 詳細なインシデントページ です。稼働チェックが失敗するとインシデントが自動生成され、その中にtraceroute、DNSクエリー、SSL証明書の状態、HTTPヘッダー、レスポンスボディ、同時間帯の関連ログまで1ページで表示されます。平均復旧時間(MTTR)短縮に直接寄与すると会社のマーケティングポイントになっています。

# Better Stack ヘルスチェック設定例(UIまたはAPI)
name: api.example.com health
url: https://api.example.com/health
method: GET
expected_status: 200
expected_body: '"status":"ok"'
check_frequency: 30  # seconds
regions:
  - us-east
  - eu-west
  - ap-northeast
notifications:
  - type: slack
    channel: '#oncall-platform'
  - type: pagerduty
    service_id: PAB123
ssl_certificate_check: true
domain_expiration_check: true

APIとTerraform Providerも提供されているため、監視設定をコードで管理できます。2025年にGAされた betterstack-elements SDKはReact/Vueコンポーネントとしてステータスページを直接埋め込むことができます。

短所は、(1) Datadog/New Relicレベルの本格的APMではない、(2) ログ保存期間が高額プランでも30~90日に制限される、(3) データ居住地(Data Residency)が米国とEUの2か所のみ、という点です。韓国・日本の顧客はデータ居住地が足りないという理由で導入を躊躇する場合があります。

3. Pingdom — SolarWinds 傘下のクラシック

Pingdomは2005年スウェーデンで始まった最も古い稼働監視SaaSの一つです。2014年にSolarWindsが買収して以降、一時停滞期を経験しましたが、「Pingdomで監視している」という文言そのものが稼働監視の同義語のように使われるほど認知度が高いです。現在も世界70万以上のウェブサイトで利用されています。

Pingdomのコア製品は2つに分かれます。

• Pingdom Uptime: 100以上の外部vantage pointからHTTP/HTTPS、TCP、UDP、DNS、SMTP、POP3、IMAPチェック
• Pingdom Real User Monitoring (RUM): JavaScriptスニペットで実ユーザーのページロード時間を計測

価格は Starter($15/月、10チェック)**、**Professional($39/月、50チェック)、Advanced($89/月) で、RUMは別途月20ドルから始まります。合成トランザクション(Synthetic Transaction)は追加費用で、トランザクション1個あたり月15~20ドル別途課金される構造のため、フル機能を使うと月数百ドル台へすぐ上がります。

# Pingdom REST API例 — チェック一覧を取得
curl -X GET https://api.pingdom.com/api/3.1/checks \
  -H "Authorization: Bearer $PINGDOM_API_TOKEN"

# チェック作成
curl -X POST https://api.pingdom.com/api/3.1/checks \
  -H "Authorization: Bearer $PINGDOM_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "api.example.com",
    "host": "api.example.com",
    "type": "http",
    "resolution": 1,
    "url": "/health",
    "encryption": true
  }'

Pingdom最大の強みは (1) ブランド認知度 と (2) 100以上のvantage point です。特にグローバルサービスで「東南アジアのユーザーが我々のサービスにアクセス可能か」を検証するときには、他のどのツールよりも圧倒的に多い計測点を提供します。

一方の弱点は (1) UI/UXが2010年代水準にとどまる、(2) 価格が競合に比べ高い、(3) 新機能追加の速度が遅い という点です。SolarWinds親会社が他製品(Loggly、AppOptics、Papertrail)へ資源を分散させた結果、Pingdom単独のイノベーションは停滞気味です。2024年のSolarWindsプライベートエクイティ買収以降、価格改定があり、無料トライアルが30日から14日へ短縮されるなど費用効率も悪化しました。

2026年現在の新規導入を考えるなら、Pingdomよりも先にBetter Stack、Checkly、Uptime Robotのいずれかを検討するのが一般的です。ただし既にSolarWindsエコシステムを利用しているなら、Pingdom + AppOptics + Logglyのバンドル割引が魅力的な場合もあります。

4. Uptime Robot — 無料50モニターの絶対王者

Uptime Robotは2010年トルコでスタートした稼働監視SaaSです。他の全製品の価格比較の基準点となる 「無料50モニター、5分間隔」 プランで有名で、2026年現在は世界200万人以上のユーザー、1000万以上のアクティブモニターを保有しています。

価格体系は次のとおりです。

• Free: 50モニター、5分間隔、基本通知
• Solo($7/月): 50モニター、1分間隔、SMS/音声通知の一部
• Team($14/月): 100モニター、30秒間隔
• Enterprise($59/月): 200モニター、30秒間隔、優先サポート

無料プランが他製品より圧倒的に充実している理由は広告収益化ではなく、「Soloへのアップグレード率」 に依存しているからです。1分チェック間隔やSMS通知などの明確な価値差があり、無料ユーザーの約5%が有料へ転換すると言われています。

# Uptime Robot v3 API — モニター一覧
curl -X POST https://api.uptimerobot.com/v3/getMonitors \
  -H "Authorization: Bearer $UPTIMEROBOT_API_KEY" \
  -d "format=json"

# モニター作成
curl -X POST https://api.uptimerobot.com/v3/newMonitor \
  -H "Authorization: Bearer $UPTIMEROBOT_API_KEY" \
  -d "type=1&url=https://example.com&friendly_name=Production%20Web"

Uptime Robotの魅力は 「個人開発者・サイドプロジェクトに最も簡単な最初の選択肢」 という点です。登録後5分でモニターを50個登録でき、別途の決済カードなしに無期限で無料利用できます。無料ステータスページ(stats.uptimerobot.com/xxx)も標準で提供されるため、小規模プロジェクトなら他ツールなしで充分です。

限界は、(1) マルチステップのシンセティック監視非対応、(2) ログ/メトリクス統合の不在、(3) on-call機能がなくPagerDuty/OpsGenieとの別途連携が必要 という点です。事実上「HTTP 200を受け取れるか確認する」という一つの仕事に特化したツールと見るのが正確です。ビジネスが成長してマルチステップチェックやインシデント管理が必要になるとBetter StackやChecklyへ移行するパターンが一般的です。

5. Updown.io — フランス発のミニマル有料サービス

Updown.ioは2014年にフランスの開発者Adrien Rey-Jarthonが1人で始めた稼働監視サービスです。12年経った2026年現在も従業員1~2人規模で運営されていますが、約5万以上のアクティブモニターを安定的に処理しています。

Updown.ioのすべての設計判断は 「単純さ」 の一語に集約されます。

• 価格は利用量ベース(モニター数ではなくチェック回数で課金)
• 1チェック = 0.000125ユーロ、つまり1分間隔で1年あたり約65ユーロ
• 無料クレジット5万回(=約35日分の1分チェック)
• UIは1ページのSPA、多言語非対応、モバイルアプリなし

これらすべての制約のおかげで価格が圧倒的に安いです。1か月に100個の1分間隔モニターを運営しても約5ユーロ程度。Pingdomと比較すれば1/10の価格です。

# Updown.io API — 全チェック取得
curl -X GET https://updown.io/api/checks \
  -H "X-API-KEY: $UPDOWN_API_KEY"

# チェック追加
curl -X POST https://updown.io/api/checks \
  -H "X-API-KEY: $UPDOWN_API_KEY" \
  -d "url=https://example.com&period=60&enabled=true"

Updown.ioは特にヨーロッパの個人開発者と小規模スタートアップの間でカルト的な支持を集めています。GitHubの有名OSSメンテナーの多くが自分のプロジェクトのAPI監視にUpdown.ioを使っていると公言しているケースが多いです。

短所は、(1) 韓国・日本のvantage pointが不足(2026年現在ヨーロッパ4、米国3、アジア2)、(2) マルチステップ監視・合成トランザクション非対応、(3) 英語中心のサポート文書。グローバルSaaSを運営する場合、vantage pointの地域多様性が不足するかもしれません。

6. Cronitor / Healthchecks.io — Cron 監視の2大巨頭

稼働監視とは別カテゴリーながら混同されやすいのが 「Cronジョブ監視」 です。これは定期的に実行されるべきバックグラウンドジョブが 「実行されなかった沈黙」 を検知するツールです。通常のHTTPチェックがサービスの生存を確認するなら、cron監視は「今日の深夜3時にバックアップが実行されたか」を確認します。

この分野の2大製品がCronitorとHealthchecks.ioです。

Healthchecks.io

2015年にラトビアの開発者Pēteris Cauneが1人で始めたオープンソースのcron監視SaaSです。無料プランが非常に充実(20チェック)で、BSDライセンスのソースコードを公開しており自己ホストも可能です。価格は Hobbyist($5/月、100)**、**Business($25/月、500)、Plus($80/月、1500) などです。

コアの利用パターンは dead man's switch(停止検出スイッチ)です。ジョブの開始と終了でping URLを叩き、予想時間内にpingが来なければ通知を出します。

# crontab例 — 毎時バックアップジョブ
0 * * * * /usr/local/bin/backup.sh && curl -fsS --retry 3 https://hc-ping.com/your-uuid

# 開始/終了/失敗をすべて報告(推奨)
0 * * * * curl -fsS --retry 3 https://hc-ping.com/your-uuid/start && /usr/local/bin/backup.sh && curl -fsS --retry 3 https://hc-ping.com/your-uuid || curl -fsS --retry 3 https://hc-ping.com/your-uuid/fail

Cronitor

2014年米国サンフランシスコで始まったcron監視SaaSです。Healthchecks.ioに比べて価格は高い(月24ドルから)ものの、(1) フル稼働チェック統合、(2) メトリクス/ログ収集、(3) Cron job statistics、(4) AWS Lambda・Kubernetes CronJobの自動認識 といった付加機能が強みです。

cronitor CLIツールをインストールすると既存のcronコマンドをラップして自動追跡します。

# Cronitor CLIインストール
brew install cronitor

# crontabの自動発見
cronitor discover

# コマンドラップ方式
0 * * * * cronitor exec backup-job /usr/local/bin/backup.sh

選択基準は単純です。「純粋なcron監視のみが必要ならHealthchecks.io、稼働/メトリクス/ログ統合が必要ならCronitor」。Healthchecks.ioは自己ホストできるためセキュリティに敏感な組織に魅力的です。

7. OneUptime — オープンソースのオールインワン監視プラットフォーム

OneUptimeは2021年に米国で始まった オープンソースのオールインワン監視プラットフォーム です。Apache 2.0ライセンスでGitHubに全コードが公開されており、同時にクラウドSaaS版も提供しています(価格はユーザーあたり月0~50ドル)。

OneUptimeの野心は 「Better Stack + Statuspage + Datadog + PagerDuty + Cachet のオープンソース版」 になることです。実際に1つの画面で次の機能をすべて提供します。

• 稼働監視(HTTP、TCP、ICMP、DNS、SSL有効期限)
• シンセティック監視(Playwright ベース)
• ステータスページのホスティング
• インシデント管理 + on-call ローテーション
• ログ収集と検索
• APM(分散トレーシング)
• ユーザー/セッション監視

セルフホストはDocker Compose一行で可能です。

# OneUptime セルフホスト
git clone https://github.com/OneUptime/oneuptime.git
cd oneuptime
cp config.example.env config.env
# config.envを編集後
docker compose up -d

OneUptimeの長所は (1) 全データをセルフホストで保有可能、(2) 1つのプラットフォームで監視・on-call・ステータスページの統合、(3) Apache 2.0ライセンスによる商用利用の自由 です。

短所は (1) インストール/運用の複雑さ(PostgreSQL、ClickHouse、Redisが全て必要)、(2) UI完成度が商用SaaSに劣る、(3) ドキュメント不足、(4) ユーザーコミュニティがまだ小さい(GitHubスター約6000) です。2026年現在、OneUptimeは「オープンソース統合監視」という市場ポジショニングで最も野心的ですが、同時に最も困難な道を歩んでいる製品です。

8. Statuscake / Hyperping / Freshping / Site24x7 — 中価格帯の競合

これら4製品はPingdomとUptime Robotの間にある中価格帯を狙う競合です。それぞれの差別点を短くまとめます。

Statuscake(英国)

2012年英国で始まった稼働監視SaaSです。無料プラン(モニター10、5分間隔)が充実しており、有料プランは Superior($24/月) から始まります。英国・EUユーザーの間でデータ居住地の理由で支持率が高いです。SSL証明書監視とドメイン期限切れ確認が同じ価格で同梱されています。

Hyperping(フランス)

2017年フランス発の比較的新しいSaaSです。「開発者フレンドリーUI」 と 無料ステータスページのホスティング が強み。価格は月19ドルから始まり、Updown.ioとPingdomの間の価格帯に位置します。2024年後半に韓国語UIを追加してアジア圏のユーザーが増えています。

Freshping(Freshworks)

Freshworks(Freshdesk、Freshservice)の無料アドオン製品として出された稼働監視です。無料50モニター、1分間隔 でUptime Robotの直接競合。Freshworksエコシステムを使う組織(Freshdeskチケットの自動生成など)に魅力的ですが、単独製品としては機能がやや弱いです。

Site24x7(Zoho)

Zoho(インド)の総合監視製品群。稼働・サーバー・ネットワーク・クラウド・APM・ログ・実ユーザー監視・ステータスページをすべて含む最も広範な製品の一つ。価格は $10/月 から始まりますが、フル機能を使うと月数百ドル台へ上がります。Datadogの低価格代替として評価されることが多いです。

9. New Relic Synthetics + Datadog Synthetic — APM統合のシンセティック監視

従来の稼働監視が「単一URLが応答するか」を見るツールなら、シンセティック監視(Synthetic Monitoring) は「実ユーザーの多段階フローが正常に動作するか」を検証するツールです。例えば「ホームページ → ログイン → 商品検索 → カートへ追加 → 決済 → 完了」という5段階フローを5分ごとに実際のヘッドレスブラウザで実行するイメージです。

この分野の2強がDatadog Synthetic MonitoringとNew Relic Syntheticsです。

Datadog Synthetic Monitoring

Datadogのシンセティック監視は2種類に分かれます。

• API Tests: 単一HTTP/gRPC/WebSocketチェック
• Browser Tests: ヘッドレスChromeでマルチステップユーザーフローを自動化

価格は API Test 10,000回/月 $5**、**Browser Test 1,000回/月$12 という利用量ベース構造。既にDatadog APM/Logs/Infrastructureを使う組織はメトリクスとシンセティックデータが同じ画面で統合される点が決定的です。

// Datadog Synthetic Browser Testスクリプト例(UIで録画後にコード出力)
await page.goto('https://example.com')
await page.click('button[data-test="login"]')
await page.fill('input[name="email"]', 'test@example.com')
await page.fill('input[name="password"]', 'password123')
await page.click('button[type="submit"]')
await page.waitForSelector('.dashboard')

New Relic Synthetics

New Relic SyntheticsはDatadogと類似していますが、「Scripted Browser」 という名のマルチステップブラウザ自動化機能をより早くから提供しました。Selenium WebDriver ベースのスクリプトで書かれ、Private Minion(セルフホストエージェント)を通じて社内ネットワークでも実行可能です。

価格は新しい利用量モデルで 最初の100GB/月は無料、その後はGBあたり $0.30。シンセティックチェックもGB使用量に含まれ、フルオブザーバビリティパッケージ(APM+Logs+Synthetics+RUM)を使うときに最もコスト効率が良くなります。

Checklyとの比較

後ほど詳述するChecklyはDatadog/New Relicのシンセティック監視部分だけを切り出し、より開発者フレンドリーにした製品です。価格はDatadogの約1/3水準ですが、APM/Logsとの統合がないため、既にオブザーバビリティスタックがある組織は統合性を理由に高くてもDatadog/New Relicを選ぶことが多いです。

10. Atlassian Statuspage — ステータスページ市場のスタンダード

ステータスページ(Status Page)はサービスのインシデントを顧客に透明に告知する公式ページです。2012年にStripeが自前で作ったstatus.stripe.comがデザインの標準になった後、Statuspage.ioがこのデザインをSaaSとして製品化し、2016年にAtlassianが買収して Atlassian Statuspage にリネームしました。

2026年現在、GitHub、AWS、Cloudflare、OpenAI、Vercel、Slack、Shopifyなどグローバル大手SaaSの90%以上がAtlassian Statuspageを使っています。「ステータスページ = Atlassian Statuspage」という認識が強く、事実上の業界標準になっています。

価格は Free(1ページ、チームメンバー2、購読者100)、Starter($29/月)**、**Growth($99/月)、Business($299/月)**、**Enterprise($1,500+/月) という構造。Enterpriseプランは SSO、監査ログ、カスタムドメイン、SLA保証を含みます。

ステータスページのコア構成要素は次のとおりです。

• Components: 監視対象(API、Web、Database、Email など)
• Component status: Operational、Degraded、Partial Outage、Major Outage
• Incidents: 進行中のインシデントと更新履歴
• Scheduled Maintenance: 予定メンテナンスの告知
• Subscribers: メール、SMS、Slack、RSS、Webhookでインシデント通知を受信
• Uptime history: コンポーネント別の90日稼働時間チャート

# Atlassian Statuspage API — インシデント作成例
curl -X POST \
  "https://api.statuspage.io/v1/pages/$PAGE_ID/incidents" \
  -H "Authorization: OAuth $STATUSPAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "incident": {
      "name": "API応答遅延を観測",
      "status": "investigating",
      "impact_override": "minor",
      "body": "現在API応答遅延を調査中です。",
      "component_ids": ["abc123"],
      "components": {"abc123": "degraded_performance"}
    }
  }'

強み: (1) 市場標準のポジション(ユーザーがデザインに慣れている)、(2) Jira/Opsgenie/Confluenceとの統合、(3) Atlassianの安定したSLA。弱み: (1) 価格が高くインフレーション頻発、(2) 機能イノベーションが遅い、(3) 新規ユーザーから見るとUIがやや重い。

11. Instatus / Cachet — ステータスページの代替案

Atlassian Statuspageの価格と重さに負担を感じた市場が生んだ代替案がInstatusとCachetです。

Instatus

2020年英国で始まったステータスページSaaSで、「Statuspageの1/3の価格、10倍速いUI」を標榜します。価格は 無料(1ページ、無制限購読者) から始まり、Starter($20/月)**、**Pro($50/月) へと上がります。

Instatusの差別点は以下のとおりです。

• サイトのロード1秒未満(Atlassian Statuspageは3~5秒)
• 無制限の購読者(Statuspage Starterは1,000名制限)
• 無料プランでもカスタムドメインを支持
• インシデントテンプレートのライブラリ(インシデント種別ごとの記述ガイド)

// Instatus API — インシデント作成
fetch('https://api.instatus.com/v1/{pageId}/incidents', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.INSTATUS_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    name: 'API latency increased',
    status: 'INVESTIGATING',
    notify: true,
    components: ['comp_abc123'],
    statuses: [{id: 'comp_abc123', status: 'PARTIALOUTAGE'}],
    started: new Date().toISOString(),
  }),
})

大口顧客事例として、OpenAIがStatuspage代替を検討後に一部子会社ページをInstatusへ移行した事例、Vercelの一部地域のステータスページなどがあります。

Cachet(OSS)

2014年英国の開発者James BrooksがPHP/Laravelで作ったオープンソースのステータスページです。BSD-3ライセンスでGitHubに公開されており、2026年現在で約17,000スターを持ちます。

セルフホストがコアで、Dockerで5分で立ち上げられます。

# Cachet Docker セルフホスト
docker run -d --name=cachet \
  -p 80:80 \
  -e APP_KEY=$(php -r "echo 'base64:'.base64_encode(random_bytes(32));") \
  -e DB_DRIVER=pgsql \
  -e DB_HOST=postgres \
  -e DB_DATABASE=cachet \
  -e DB_USERNAME=cachet \
  -e DB_PASSWORD=secret \
  cachethq/docker:latest

Cachetの限界は、(1) 2020年以降メンテナー活動が減り更新が遅くなった、(2) PHP依存が重い、(3) UIがやや古い、という点です。2026年に新規導入を検討するなら、次に紹介する Uptime Kuma がより現代的な代替案です。

その他 — Hund

HundはSaaSステータスページ市場の新興プレイヤーで、インシデント自動化とコンポーネントのグループ化に強みがあります。価格は月59ドルからでInstatusより高いがAtlassian Statuspageより安いです。中小企業が両者の間で比較する選択肢としてよく登場します。

12. Uptime Kuma — Docker による最も人気の OSS セルフホスト

Uptime Kumaは2021年に香港の開発者Louis Lamが個人サイドプロジェクトとして始めたオープンソースの稼働監視ツールです。2026年5月現在GitHubスター約65,000で セルフホスト稼働監視の事実上のスタンダード になっています。

インストールはDocker一行です。

# Uptime Kuma セルフホスト — 単一Dockerコンテナ
docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:1

# Docker Compose版
# docker-compose.yml
version: '3.3'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    volumes:
      - ./uptime-kuma-data:/app/data
    ports:
      - "3001:3001"
    restart: always

Uptime Kumaの魅力は (1) 1つのコンテナにすべての機能、(2) Pingdom級のUI完成度、(3) 90以上の通知チャネル(Slack、Discord、Telegram、メール、SMS、Webhook、ntfy、Gotify など)、(4) 自前のステータスページのホスティング内蔵、(5) 非常に活発なコミュニティ です。

サポートするチェック種別も豊富です。

ステータスページもワンクリックで生成され、カスタムドメインとパスワード保護にも対応。2024年リリースの Uptime Kuma 2.0 ベータはPostgreSQLバックエンド対応、マルチインスタンス同期、データ保持ポリシーが追加されました。

限界は (1) 単一インスタンスSPOF(2.0で改善中)、(2) マルチvantage pointの不在(自分のサーバーからのみチェック)、(3) エンタープライズ機能の不足(SSO、監査ログ など) です。とはいえ個人開発者、ホームラボ、SMBには価格対価値が圧倒的です。

13. Gatus — YAML 設定一ファイルの Go ベース監視

Gatusは2019年にカナダの開発者Tristan Webberが作った Goベースのオープンソース監視ツール です。Uptime Kumaの直接競合ですがデザイン哲学が全く違います。

• Uptime Kuma: UI中心、クリックで設定、データベースに保存
• Gatus: YAMLファイル一つで全設定、GitOpsフレンドリー、コードレビュー可能

Gatusのすべての監視は単一YAMLファイルで定義されます。

# config.yaml — Gatus全設定
storage:
  type: postgres
  path: "postgres://user:password@localhost:5432/gatus?sslmode=disable"

endpoints:
  - name: api-health
    group: production
    url: https://api.example.com/health
    interval: 30s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 500"
      - "[BODY].status == ok"
    alerts:
      - type: slack
        send-on-resolved: true

  - name: database-tcp
    group: production
    url: tcp://db.internal:5432
    interval: 1m
    conditions:
      - "[CONNECTED] == true"

  - name: certificate-check
    url: https://example.com
    interval: 1h
    conditions:
      - "[CERTIFICATE_EXPIRATION] > 168h"

alerting:
  slack:
    webhook-url: "https://hooks.slack.com/services/..."
    default-alert:
      description: "Service down"
      send-on-resolved: true
      failure-threshold: 3

Gatusの強み: (1) YAMLファイルをGitでバージョン管理可能、(2) Helm ChartでKubernetesデプロイをファーストクラス対応、(3) PostgreSQL/SQLite/メモリバックエンドの選択可、(4) Prometheusメトリクスのエクスポート、(5) メンテナンスウィンドウの定義が可能 です。

# Gatus Dockerデプロイ
docker run -d \
  -p 8080:8080 \
  -v $(pwd)/config:/config \
  --name gatus \
  twinproduction/gatus:latest

# Kubernetes Helmチャートデプロイ
helm repo add twin https://twin.github.io/helm-charts
helm install gatus twin/gatus

限界は (1) UIが単純(Uptime Kumaほど派手ではない)、(2) マルチユーザー/チーム管理がない、(3) シンセティック監視がない です。しかしDevOps/SREチームが運営する環境では 「監視をコードで」 という哲学に最も合うツールです。

14. Checkly — Playwright ベースのシンセティック監視の新星

Checklyは2018年にドイツのベルリンで始まったシンセティック監視SaaSです。「開発者のためのシンセティック監視」 を標榜し、Playwrightベースのコード型監視がコア差別点です。2023年シリーズBで5300万ドルを調達し、2026年現在は従業員約100人規模で急成長中です。

Checkly最大のイノベーションは 「Monitoring as Code」 です。すべての監視をTypeScript/JavaScriptコードで定義しGitでバージョン管理します。

// __checks__/api-health.check.ts
import { ApiCheck, AssertionBuilder } from 'checkly/constructs'

new ApiCheck('api-health-check', {
  name: 'API Health Check',
  alertChannels: [],
  degradedResponseTime: 1000,
  maxResponseTime: 5000,
  request: {
    method: 'GET',
    url: 'https://api.example.com/health',
    assertions: [
      AssertionBuilder.statusCode().equals(200),
      AssertionBuilder.jsonBody('$.status').equals('ok'),
      AssertionBuilder.responseTime().lessThan(500),
    ],
  },
})

// __checks__/checkout-flow.spec.ts (Playwrightブラウザテスト)
import { test, expect } from '@playwright/test'

test('checkout flow', async ({ page }) => {
  await page.goto('https://example.com')
  await page.click('text=Sign in')
  await page.fill('[name=email]', 'test@example.com')
  await page.fill('[name=password]', process.env.TEST_PASSWORD!)
  await page.click('button[type=submit]')
  await expect(page).toHaveURL(/dashboard/)
})

CLIでデプロイします。

# Checkly CLI
npm install -g checkly
checkly login
checkly deploy

# CI/CDでPRごとに作成されるプレビューデプロイ
checkly trigger --record

Checklyの強み: (1) Playwright標準の採用(別途DSL学習が不要)、(2) GitOpsフレンドリー、(3) 次世代UI、(4) Vercel/Netlifyデプロイとの自動連携、(5) Datadog/Slack/PagerDuty統合。

価格は Free(5チェック、API 10,000回/月)、Hobby($14/月)**、**Team($80/月)、Enterprise($300+/月) です。Datadog Syntheticの約1/3価格で、オブザーバビリティスタックを最初に構築するスタートアップに魅力的です。

限界は (1) APM/Logsとの統合がない(Datadogと違い)、(2) マルチvantage pointが5でPingdomより少ない、(3) 韓国語/日本語UIがない です。それでも2026年のシンセティック監視カテゴリーで 最も急成長中の製品 です。

15. 韓国 と 日本 — トス、カカオ、メルカリ、NTT の実例

韓国と日本の大手インターネット企業はどの稼働監視ツールを使っているでしょうか。公開資料と技術ブログを元に整理します。

韓国 — トス、カカオ

トス(ビバリパブリカ) は2024年のSLASHカンファレンスで自社構築した監視システム TIMS(Toss Infrastructure Monitoring System) を公開しました。Prometheus + Grafana + Lokiベースのメトリクス/ログスタック上で、外部稼働チェックはDatadog Syntheticを使い、内部cron監視は独自システムを運用します。ステータスページはNext.jsアプリで自社の Toss デザインシステムを適用して作成しており、外部 SaaS は使いません。

カカオ は韓国最大規模の監視インフラを運用しています。2022年のSK C&Cデータセンター火災事件以降、次の変化がありました。

• マルチクラウドvantage pointの拡大(AWS、GCP、Naver Cloudのすべてでチェック)
• カカオトーク独自のステータスページ(status.kakao.com)を新設
• インシデント発生時、カカオトークのプッシュでユーザーへ直接告知するチャネルを統合
• インシデント管理ツールを自社開発(Atlassian Statuspage導入を検討後に自社構築を決定)

日本 — メルカリ、NTT

メルカリ は2023年に自社のSREブログで監視スタックを公開しました。

• メトリクス: Datadog + Prometheus
• シンセティック監視: Datadog Synthetic + 独自のPlaywrightスクリプト
• ステータスページ: Atlassian Statuspage(status.mercari.com)
• on-call: PagerDuty
• インシデント自動生成: Datadog → Statuspage の自動連携ワークフロー

NTT は日本の通信インフラ企業らしく、自社の監視システムを運用します。外部SaaSは補助ツールにとどめ、コアインフラはZabbixベースの自社構築監視とNTT内部NMS(Network Management System)に依存します。外部ステータスページは別運用者が手動更新する伝統的方式を維持しています。

韓国・日本ユーザーのツール選択傾向

日本市場で興味深いのは Mackerel(はてなが運営する日本産の監視SaaS)がSMB市場で依然強力なことです。日本語のUI/ドキュメント、JPY決済、日本の SaaS との連携(Slackの日本法人、Microsoft Teams Japan など)が強みです。

16. 誰が何を選ぶべきか — 個人 / スタートアップ / OSS / エンタープライズ

ここまで見てきた20以上の製品の中からどれを選ぶべきか。利用者タイプ別の推奨を整理します。

個人開発者 / サイドプロジェクト

• 第一の選択肢: Uptime Robotの無料プラン(50チェック、無期限無料)
• セルフホスト志向: Uptime Kuma(Docker一行)
• cron監視を追加: Healthchecks.ioの無料(20チェック)
• ステータスページが必要: Instatus無料 または Uptime Kuma 内蔵

シード ~ シリーズAスタートアップ

• 統合ツール1つで完結したい: Better Stack($29 ~$99/月)
• シンセティック監視が必要: Checkly($14 ~$80/月) + Uptime Robot
• オブザーバビリティスタックを最初に構築: Datadogの14日無料 後に費用を検討
• ステータスページ: Instatus($20/月) または Better Stack 内蔵

シリーズB以降の成長段階企業

• APM + シンセティック統合: Datadog Synthetic($30 ~$300/月)
• もしくはDatadog代替: New Relicの100GB無料 を活用
• インシデント管理: PagerDuty + incident.io
• ステータスページ: Atlassian Statuspage(業界標準)
• Cron: Cronitor(Lambda/K8s自動認識)

エンタープライズ

• オブザーバビリティのコア: Datadog または New Relic(全社ライセンス)
• シンセティック監視: Datadog/NR内蔵 + Checkly Enterprise(CI/CD統合)
• ステータスページ: Atlassian Statuspage Enterprise($1,500+/月) + Confluence統合
• On-call: PagerDuty Enterprise または Opsgenie
• データ居住地の懸念: 韓国/日本は自社構築 + Datadog補助

セキュリティ/規制業界(金融、医療、政府)

• セルフホスト必須: OneUptime セルフホスト、Uptime Kuma、Gatus の組み合わせ
• メトリクス/ログ: Prometheus + Grafana + Loki を自社構築
• ステータスページ: Cachet または自前のNext.js/Hugoによる静的ページ

結論

稼働監視は2026年に 「統合製品 vs 専門製品 + 糊付けツール」 という2軸へ進化しました。個人開発者からシードのスタートアップまでは、Uptime Robot、Better Stack、Uptime Kumaのような統合製品1つで充分です。シリーズB以降になるとシンセティック監視が必須になり、エンタープライズになるとオブザーバビリティスタック全体をDatadog/New Relicのようなフルスタックプラットフォームで統合するパターンが一般的です。

最も重要な原則はたった一つです。「監視されていないダウンタイムは真のダウンタイムになる」。どのツールを選ぶにせよ、まず導入してデータを蓄積することが最優先です。

参考 / References

• Better Stack — https://betterstack.com/
• Better Stack 統合発表(2023年8月) — https://betterstack.com/community/news/introducing-better-stack/
• Pingdom — https://www.pingdom.com/
• SolarWinds Pingdom — https://www.solarwinds.com/pingdom
• Uptime Robot — https://uptimerobot.com/
• Updown.io — https://updown.io/
• Cronitor — https://cronitor.io/
• Healthchecks.io — https://healthchecks.io/
• Healthchecks GitHub (OSS) — https://github.com/healthchecks/healthchecks
• OneUptime — https://oneuptime.com/
• OneUptime GitHub — https://github.com/OneUptime/oneuptime
• Statuscake — https://www.statuscake.com/
• Hyperping — https://hyperping.com/
• Freshping — https://www.freshworks.com/website-monitoring/
• Site24x7 — https://www.site24x7.com/
• Datadog Synthetic Monitoring — https://www.datadoghq.com/product/synthetic-monitoring/
• New Relic Synthetics — https://newrelic.com/platform/synthetic-monitoring
• Checkly — https://www.checklyhq.com/
• Checkly CLI — https://www.checklyhq.com/docs/cli/
• Atlassian Statuspage — https://www.atlassian.com/software/statuspage
• Statuspage API — https://developer.statuspage.io/
• Instatus — https://instatus.com/
• Cachet — https://cachethq.io/
• Cachet GitHub — https://github.com/CachetHQ/Cachet
• Hund — https://hund.io/
• Uptime Kuma — https://uptime.kuma.pet/
• Uptime Kuma GitHub — https://github.com/louislam/uptime-kuma
• Gatus GitHub — https://github.com/TwiN/gatus
• Standard Webhooks — https://www.standardwebhooks.com/
• Mercari Engineering Blog — https://engineering.mercari.com/
• Toss SLASH 2024 — https://toss.tech/slash-24
• Mackerel (Hatena) — https://mackerel.io/