Webサイト死活監視の始め方【2026年】落ちても気づけない問題を解決する

バックアップ・障害対策・監視初級2026年6月26日

Monitoring Uptime Kuma ConoHa VPS Xserver VPS SSL Webhook Slack

本記事はアフィリエイト広告（A8.net）を含みます。価格・仕様は2026年6月時点の目安です。最新は各公式サイトでご確認ください。

TL;DR

サイトが落ちても、運営者は自分でアクセスしないと気づきません。監視ツールを入れると、サーバーが応答を返さなくなった瞬間にメールやSlackへ通知が届くようになります。

まず何をするか、結論だけ言うと——UptimeRobotの無料プランに登録して、監視対象URLを1件登録する。これだけで「5分ごとにサイトを確認し、落ちたら通知する」仕組みが動きます。登録はメールアドレスだけで済み、クレジットカードも不要です。

やりたいこと	手段
とにかく落ちたら通知が欲しい	UptimeRobot 無料プラン（メールのみ・5分間隔）
Slack・Webhookにも飛ばしたい	UptimeRobot 有料 or Uptime Kuma（自前サーバー）
SSL証明書の期限切れを事前に検知したい	Uptime Kuma の Certificate Expiry Monitor
アラートが多すぎて慣れてしまった	連続失敗2〜3回後のみ通知する設定に変える

なぜ監視が必要なのか

Webサイトが落ちても、運営者は自分でアクセスしなければ気づきません。

ユーザーからの問い合わせで初めて障害を知る、という状況は珍しくありません。そのとき、ダウンタイムはすでに数時間に達していることがあります。ECサイトなら売上の直接損失、問い合わせフォームやLP（ランディングページ）なら問い合わせ機会の損失です。

監視ツールは「落ちた事実」を記録するだけでなく、落ちた瞬間に通知を飛ばすことで、障害への対応時間を短縮するための仕組みです。

監視の種類を整理する

「監視」という言葉はいくつかの意味で使われます。目的に合わないツールを選ばないよう、違いを整理します。

死活監視（Ping / ICMP）

サーバー自体がネットワーク上で生きているかを確認する、最もシンプルな手法です。ただし、サーバーが生きていてもWebサービスが落ちているケースには対応できません。「サーバーは動いているのにサイトが表示されない」という状況はよく起きます。

外形監視（HTTP/HTTPS チェック）

外形監視って何？ 「外から見た監視」という意味です。外部のネットワークから実際にHTTPリクエスト（ブラウザがページを取りに行くのと同じ動作）を送り、ちゃんと200 OKが返ってくるかを確認します。ユーザーと同じ目線でサービスの状態を確認できるため、実用上はこれを一番に設定するのが正解です。

メトリクス監視（CPU・メモリ・ディスク）

メトリクスって何？ サーバーの内部状態を数値（指標）で追うことです。「CPUが90%を超えたら警告」「ディスクが残り10%を切ったら通知」といった使い方をします。Prometheus + Grafana の構成が代表的ですが、これは外形監視を設定したあとのステップです。

ログ監視

アプリケーションログやNginxのエラーログを解析して異常を検知する手法です。エラーが増え始めた兆候をつかむのに使います。最初に手をつける必要はありません。

外形監視で何を見るか

外形監視で確認すべき項目は4つです。重要度順に並べると次のようになります。

HTTPステータスコード

サーバーがリクエストに返すコードです。200番台が正常、500番台はサーバー側のエラーを意味します。監視ツールでは「200以外をエラーとみなす」設定にするのが基本です。

応答時間（レイテンシ）

レイテンシって何？ リクエストを送ってからレスポンスが返るまでの時間のことです。サイトが遅い、という体感はここに出ます。

「応答は返ってくるが異常に遅い」という状態も検知できます。通常の2〜3倍に跳ね上がった場合をアラートのトリガーにする設計も有効です。

レスポンスボディの検証（キーワードチェック）

ステータス200を返しつつも、実際のページ内容がメンテナンス画面やエラーメッセージになっているケースがあります。監視ツールの「キーワードが含まれているか」機能を使うと、ページ本文に特定の文字列（例: ページタイトルの一部）が存在するかを確認できます。

SSL/TLS証明書の期限

SSL証明書って何？ URLが https:// で始まるサイトに必要な「暗号化通信の証明書」です。期限が切れると、訪問者のブラウザに「この接続は安全ではありません」という警告が表示されます。

Let’s Encrypt の証明書は90日で期限切れになります。自動更新が正常に動いていれば問題ありませんが、更新に失敗した状態で放置すると警告が出てユーザーが離脱します。期限の30日前・14日前に通知を受け取る設定を入れておくのが安全です。

Let’s Encrypt と certbot の設定については Let’s Encrypt 無料HTTPS証明書をCertbotで取得・自動更新するを参照してください。

「自分でサーバーを立てる」か「SaaSを使う」か

監視ツールには2種類あります。

SaaS型：UptimeRobot / Better Uptime / Freshping

SaaSって何？ Software as a Service の略で、「誰かが運営しているWebサービス」として提供される形態です。自分でサーバーを用意する必要がなく、ブラウザから登録するだけで使えます。

外部のネットワークから監視するため、自分のサーバーが落ちているときでも監視が継続するのが最大の強みです。インフラの知識がなくても使えます。

サービス	無料プランの制限	有料の最小プラン（目安）
UptimeRobot	監視50件・5分間隔	$7/月〜（1分間隔）
Better Uptime	監視10件・3分間隔	$20/月〜
Freshping	監視50件・1分間隔	無料で1分間隔まで対応

※料金は公式サイトで最新値を確認してください。プラン体系は変更されることがあります。

監視を始めるなら UptimeRobot の無料プランか Freshping が入口として現実的です。 5分間隔の制限はありますが、設定なしで今日から使えます。1分間隔が必要になったら有料プランへ移行する流れで十分です。

セルフホスト型：Uptime Kuma

Uptime Kumaって別サービス？費用は？ Uptime Kuma は、無料のオープンソースソフトウェアです。自分が用意したサーバー（VPSや自宅サーバー）上で動かします。ソフト自体の費用は0円ですが、動かすためのサーバー（VPS）が必要です。

Dockerで起動するWebUIが整った監視ツールです。HTTP・TCP・DNS・SSL期限・Pingなど複数の監視タイプをカバーし、監視データはサーバー内のSQLiteに保存されます。

メリット:

監視対象の数に制限がない
監視間隔を細かく設定できる（最短20秒程度）
Slack・Discord・Telegram・Email・Webhookなど通知先が豊富
ステータスページを外部公開できる

デメリット:

Uptime Kuma を動かすサーバー自体が落ちると監視できなくなる（SaaS型との組み合わせで補完するのが一般的）
サーバーの管理コストが増える

VPS上に環境を構築している場合は Uptime Kuma が選択肢に入ります。VPSサーバーセットアップの基本も合わせて参照してください。

Uptime Kuma のセットアップ手順

Docker Compose で起動する

Dockerって何？ アプリケーションをコンテナという箱に入れて動かす仕組みです。ここではサーバー上で docker compose up -d と打つだけで Uptime Kuma が起動します。

mkdir -p /opt/uptime-kuma && cd /opt/uptime-kuma

docker-compose.yml:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - uptime-kuma-data:/app/data

volumes:
  uptime-kuma-data:

docker compose up -d

ポートを 127.0.0.1:3001 にバインドして Nginx 経由でのみアクセスさせる構成にしています。ポートをそのままインターネットに公開しないことが重要です。

Nginx リバースプロキシ設定

server {
    listen 443 ssl;
    server_name status.example.com;

    ssl_certificate     /etc/letsencrypt/live/status.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/status.example.com/privkey.pem;

    location / {
        proxy_pass         http://127.0.0.1:3001;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;

        # WebSocket（Uptime Kuma のリアルタイム更新に必要）
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
    }
}

server {
    listen 80;
    server_name status.example.com;
    return 301 https://$host$request_uri;
}

監視の追加

ブラウザで https://status.example.com にアクセスし、初回は管理者アカウントを作成します。

「Add New Monitor」をクリック
Monitor Type: HTTP(s) を選択
URL に監視対象のエンドポイントを入力
Heartbeat Interval: 60秒（本番環境では短縮を検討）
Retries: 2〜3（後述のアラート設計を参照）
「Save」

SSL証明書期限の監視を追加する

Monitor Type に SSL Certificate を選択し、ドメインを入力します。証明書の有効期限が設定した日数（例: 30日）を下回ったタイミングでアラートが上がります。

通知チャンネルの設定

Slack Webhook

WebhookってSlackとは別のサービス？ Webhookは「特定のURLにデータを送ると何かが起きる仕組み」のことです。Slackが提供している専用URLに通知データを送ると、指定したSlackチャンネルにメッセージが届きます。

Uptime Kuma の Settings → Notifications → Add Notification から Slack を選択します。

Slack 側の操作:

Slack API でアプリを作成
Incoming Webhooks を有効化
通知先チャンネルを指定して Webhook URL を取得
Uptime Kuma に Webhook URL を貼り付ける

メール通知（SMTP）

Settings → Notifications → Add Notification → Email (SMTP) を選択します。Gmailを使う場合はアプリパスワードが必要です（2段階認証有効時）。アプリパスワードはGoogleアカウントのセキュリティ設定から発行できます。

Webhook（汎用）

任意のエンドポイントに JSON でアラートを投げる設定です。PagerDuty・Opsgenieなどのオンコール管理サービスとの連携に使います。

アラート疲れを防ぐ閾値設計

監視を始めてしばらくすると、誤検知や一時的な遅延でアラートが頻発する状態になることがあります。通知が多すぎると本当に重要なアラートを見落とすようになります。これをアラート疲れ（Alert Fatigue）と呼びます。

連続失敗N回後のみ通知する

Uptime Kuma では Monitor 設定の「Retries before unhealthy」で設定できます。

設定値	動作
1	1回失敗で即アラート（誤検知が多くなりやすい）
2〜3	2〜3回連続失敗でアラート（推奨）
5以上	ダウンタイムが長引いてからアラート（検知が遅れるリスク）

監視間隔60秒・リトライ3回であれば、3〜4分の連続障害で初めてアラートが飛ぶ計算になります。一時的なネットワーク揺れを除外しつつ、実質的な障害を検知できる設定として現実的な値です。

回復通知もセットで設定する

障害が解消したときに「復旧しました」という通知を受け取れる設定を入れておきます。Uptime Kuma では通知設定の「Notify on recovery」にチェックを入れます。復旧通知がないと、ずっと障害中なのかどうかを別途確認しに行く必要が生じます。

監視間隔を目的に合わせる

全ての監視を同じ間隔にする必要はありません。

監視対象の性質	推奨間隔
決済・予約・ログイン	30〜60秒
一般ページ・ブログ	3〜5分
管理画面・内部ツール	5〜10分

SSL証明書期限切れへの対処

証明書期限の30日前にアラートが来たとき、まず確認するのは自動更新の設定状態です。

# certbot の自動更新タイマー確認（Ubuntu / systemd）
systemctl status certbot.timer

# 手動でドライランを実行して更新が通るか確認する
certbot renew --dry-run

--dry-run では実際の証明書は更新されませんが、更新処理が正常に完了するかを事前に検証できます。エラーが出た場合は Nginx の設定変更や DNS の問題が原因のことが多いです。

更新に失敗している場合はログで原因を確認します:

journalctl -u certbot -n 50

まとめ

項目	ポイント
最初の一手	UptimeRobot 無料プランに登録して、監視URLを1件追加する
外形監視の対象	HTTP ステータス・応答時間・SSL 期限の3点が最低限
セルフホスト vs SaaS	管理コストを許容できるなら Uptime Kuma、そうでなければ SaaS 無料プランから始める
アラート設計	連続失敗2〜3回後に通知・復旧通知もセットで設定
SSL証明書	30日前アラート + dry-run で更新の疎通確認

監視を始めること自体が目的ではなく、障害に対する反応時間を短縮することが目的です。通知が来たときに何をすべきかをメモにまとめておくと、深夜の障害対応でも判断ブレが起きにくくなります。

各サービス公式

ConoHa VPS

Xserver VPS

バックアップ・障害対策・監視Prometheus + GrafanaをVPSに入れる最小構成:サーバー監視を自前で始める手順バックアップ・障害対策・監視サイトが表示されない・繋がらない。いま確認する5つのことバックアップ・障害対策・監視Linuxサーバーのリソース監視 — top/htopでボトルネックを見つける

記事一覧に戻る