※本記事の末尾に、当サイトの紹介リンク（アフィリエイトリンク）を1本掲載しています。筆者はUptimeRobotのアフィリエイトプログラムに参加しており、そのリンクを経由して有料の契約が発生した場合に紹介報酬を受け取ります。報酬の有無によって、本記事の測定結果や記述を変えることはしていません。
著者: 佐藤優太（Web制作事業 MOVON 代表） ｜ 公開日: 2026-08-16 ｜ 最終更新日: 2026-08-21
この記事は筆者が実際に登録・操作して計測した結果に基づいています。計測条件・計測日・証跡は本文中に明記しています。
本サイトの編集方針: 運営者情報
- 結論（先に答え）
- UptimeRobot無料プランの説明が、公式ページの中で食い違っていた
- 食い違っていた6項目の一覧
- UptimeRobotの使い方：実機で確かめた手順と、そのときの画面表示
- UptimeRobot無料プランで使える通知連携5つの正体
- UptimeRobot無料プランのAPIは「読めるが書けない」
- タイムスタンプが9時間ずれる場所がある
- UptimeRobotの通知は、サイトが落ちてから何分で届くか
- 監視しているのは米国のサーバーだった
- チェック間隔は本当に5分ちょうどか
- 無料のステータスページには「検索避けができない」という落とし穴がある
- UptimeRobotの登録方法でつまずいた点（マジックリンクなら通った）
- 結局、UptimeRobot無料プランで何ができるのか（まとめ表）
- UptimeRobot無料プランについてよくある質問
- この記事の測定の限界
- 本記事で検証したサービスへのリンク
結論（先に答え）
- UptimeRobotの料金ページには、Freeプランのカードと、同じページの下にある機能比較表の2か所に無料プランの説明があります。この2か所が6項目で食い違っていました【一次: UptimeRobot 料金ページ, 2026-08-16, https://uptimerobot.com/pricing/】
- 食い違ったのは API monitoring／UDP monitoring／Location-specific monitoring／Slow response alerts／DNS monitoring／SSL & Domain exp. monitor の6つ。Freeプランのカードは「無料で使える」と列挙し、機能比較表のFree列は6つとも×でした【一次: UptimeRobot 料金ページ, 2026-08-16, https://uptimerobot.com/pricing/】
- 実際にフリープランのアカウントを作って確かめたところ、正しかったのは機能比較表のほうでした。モニター作成画面でDNS・API・UDPの3種別には「Available only in Solo, Team and Scale.」と表示され、SSL・ドメイン期限のチェックには「Premium feature」、監視ロケーションの追加はアップグレードのモーダルで止められました【実測: n=1, 2026-08-16, ダッシュボードのモニター作成画面】
- 無料で作れるモニターの種別は 4つだけ（HTTP／Keyword／Ping／Port）。残る4種別（Heartbeat／DNS／API／UDP）は有料プラン限定でした【実測: n=1, 2026-08-16, モニター作成画面のMonitor typeセレクタ】
- モニター上限 50件、最短チェック間隔 5分 は表示どおりでした。間隔の選択肢は5分・30分・1時間・12時間・24時間の5段階で、15秒・30秒・1分には「Premium feature」が付いています【実測: n=1, 2026-08-16, ダッシュボードとモニター作成画面】
- 料金ページの「Only 5 integrations」は正しく、無料で使える連携は5つでした。ただしその5つは Discord・Google Chat・Splunk・Pushbullet・Pushover で、SlackもWebhookも入っていません【実測: n=1, 2026-08-16, ダッシュボードのIntegrations & API画面】
- APIキーは無料で発行できました。ただし読み取りだけです。モニターを作る
newMonitorは、パラメータを4通り変えて試してもすべてaccess_deniedで拒否されました【実測: n=1, 2026-08-16, API v2 のレスポンス】 - 通知の速さは十分でした。モニターを作ってから76秒でダウンが確定し、そこから9秒以内にメールが届いています【実測: n=1, 2026-08-16, モニター詳細画面とアラートメールのタイムスタンプ】
- ただし監視元は米国（Ashburn, USA）でした。無料プランでは監視ロケーションを選べないため、日本国内のサーバーを日本から監視することはできません【実測: n=1, 2026-08-16, アラートメールのLocation欄とモニター詳細画面のRegions】
- 無料のステータスページは1つ作れますが、検索避け（noindex）にできません。発行されたURLを未ログインで開くとHTTP 200で表示され、HTMLには
<meta name="robots" content="index">が入っていました【実測: n=1, 2026-08-16, 発行URLへの匿名アクセス】 - クレジットカードの入力は最後まで一度も求められませんでした【実測: n=1, 2026-08-16, 登録からダッシュボードまでの全画面】
この記事で実測したサービス（当サイトの紹介リンク・無料利用では報酬は発生しません）
▶ UptimeRobot 公式サイトを見る （無料プランあり・カード不要）
UptimeRobot無料プランの説明が、公式ページの中で食い違っていた
サイトやサーバーが落ちたときに気づけるようにしておく「死活監視」は、個人でサイトを持っている人にも必要な仕組みです。UptimeRobotはその分野でよく名前が挙がるサービスで、無料プランで50件も監視できると案内されています【一次: UptimeRobot 料金ページ, 2026-08-16, https://uptimerobot.com/pricing/】。
ところが料金ページを読んでいて、おかしなことに気づきました。
同じ1枚のページの中に、無料プランの説明が2か所あります。上のほうにあるプランのカードと、下のほうにある機能比較表です。この2つを1行ずつ突き合わせると、いくつかの項目で内容が逆になっていました。
たとえばSSL証明書の期限監視。カードのほうには、無料プランで使える機能の一覧として、こう書かれています【一次: UptimeRobot 料金ページ Freeプランのカード, 2026-08-16, https://uptimerobot.com/pricing/】。
SSL & Domain exp. monitor
一方、同じページの機能比較表で「SSL monitoring」の行を見ると、Free列には×（バツ印）が付いています【一次: UptimeRobot 料金ページ 機能比較表, 2026-08-16, https://uptimerobot.com/pricing/】。
どちらかが間違っています。無料で始めようとしている人にとっては、「証明書の期限切れも見張ってくれる」と思って選ぶのか、「それは有料だ」と分かって選ぶのかで、判断が変わります。
そこで実際に無料アカウントを作り、管理画面で1つずつ確かめました。
食い違っていた6項目の一覧
まず、突き合わせの結果を表にします。「Freeプランのカード」は無料で使えると書いてある側、「機能比較表」は同じページの下部にある表のFree列です。
| 機能 | Freeプランのカードの記載 | 機能比較表のFree列 | 実機で確かめた結果 |
|---|---|---|---|
| API monitoring | 無料で使えると列挙 | × | 使えない（モニター種別が有料限定） |
| UDP monitoring | 無料で使えると列挙 | × | 使えない（モニター種別が有料限定） |
| Location-specific monitoring | 無料で使えると列挙 | × | 使えない（アップグレードのモーダル） |
| Slow response alerts | 無料で使えると列挙 | × | 未確認（下記のとおり実機で裏を取れていません） |
| DNS monitoring | 無料で使えると列挙 | × | 使えない（モニター種別が有料限定） |
| SSL & Domain exp. monitor | 無料で使えると列挙 | × | 使えない（Premium feature表示） |
【一次: UptimeRobot 料金ページ, 2026-08-16, https://uptimerobot.com/pricing/】【実測: n=1, 2026-08-16, ダッシュボードのモニター作成画面】
6項目のうち5項目は管理画面で確かめられました。「Slow response alerts（応答が遅いときのアラート）」だけは、管理画面のどこで有効・無効が分かるかを特定できず、実機での確認ができていません。 この1行だけは「比較表にそう書いてある」という段階にとどまります。正直に書いておきます。
なお、有料プランの説明のほうを読むと、比較表と同じ理解になります。Soloプランの説明は「Everything in Free, plus（無料プランの全部に加えて）」として、次の項目を挙げています【一次: UptimeRobot 料金ページ Soloプランのカード, 2026-08-16, https://uptimerobot.com/pricing/】。
All monitor types + SSL & DNS
「無料プランに加えて、全部のモニター種別とSSL・DNS」と書いてあるということは、無料プランには全部のモニター種別もSSLも入っていないということです。3か所のうち2か所（比較表とSoloの説明）が一致していて、Freeプランのカードだけが浮いている、という構図でした。
UptimeRobotの使い方：実機で確かめた手順と、そのときの画面表示
モニターの種別は4つしか選べなかった
https://dashboard.uptimerobot.com/monitors/new/http を開いて、いちばん上の「Monitor type」のセレクタを開くと、8つの種別が並びます。このうち後半の4つには、説明文の下にラベルが付いていました【実測: n=1, 2026-08-16, モニター作成画面のMonitor typeセレクタ】。
Available only in Solo, Team and Scale. Upgrade now
このラベルが付いていたのは、Cron job / Heartbeat monitoring・DNS monitoring・API monitoring・UDP monitoring の4つです。ラベルが付いていなかった（＝無料で選べた）のは、HTTP / website monitoring・Keyword monitoring・Ping monitoring・Port monitoring の4つでした。
料金ページのFreeプランのカードには「API monitoring」「UDP monitoring」「DNS monitoring」が無料の機能として並んでいますが、管理画面では3つとも有料プラン限定でした。
ここで1つ補足しておきます。料金ページのカードにある「API monitoring」という言葉は、「APIエンドポイントを監視する機能」という意味にも、「UptimeRobotをAPIから操作できる」という意味にも読めます。管理画面のモニター種別としての「API monitoring」の説明は「Validate API responses with JSON assertions.（APIの応答をJSONアサーションで検証する）」なので、前者です。後者のAPI操作については後述しますが、そちらはそちらで無料には制限がありました。
SSL・ドメイン期限のチェックは「Premium feature」
同じモニター作成画面を下にスクロールすると、「SSL certificate and Domain checks」という見出しがあります。その右に「Premium feature」というラベルが付いていて、開くことができませんでした【実測: n=1, 2026-08-16, モニター作成画面】。
作成済みのモニターの詳細画面でも同じでした。画面下部に「Domain & SSL.」というブロックがあり、「Domain valid until」「SSL certificate valid until」の値が両方とも「Unlock」という表示になっています【実測: n=1, 2026-08-16, モニター詳細画面】。
監視ロケーションの追加はモーダルで止められた
モニター作成画面の「Location to monitor from」は、既定で「Default (auto-select by UptimeRobot)」になっています。その隣の「Add location」を押すと、モーダルが出ました【実測: n=1, 2026-08-16, モニター作成画面】。
Unlock more with a paid plan.
Upgrade to unlock the features.
このモーダルに並んでいるSoloプランの説明にも「Multi-location monitoring」が入っていました。つまり、監視する場所を選ぶのは有料プランの機能です。
チェック間隔は5分が下限だった
「Monitor interval」はスライダーで、目盛りは 15s・30s・1m・5m・30m・1h・12h・24h の8段階です。このうち 15s・30s・1m の3つには「Premium feature」というラベルが付いていて、選べませんでした【実測: n=1, 2026-08-16, モニター作成画面】。
スライダーの上にはこう書かれています。
Your monitor will be checked every 5 minutes. We recommend to use at least 1-minute checks available in paid plans
無料プランの最短が5分であることは、料金ページの記載どおりでした。
UptimeRobot無料プランで使える通知連携5つの正体
料金ページのFreeプランのカードには「Only 5 integrations（連携は5つだけ）」と書かれています【一次: UptimeRobot 料金ページ, 2026-08-16, https://uptimerobot.com/pricing/】。この数字自体は正しかったのですが、「どの5つか」は書かれていません。
管理画面の Integrations & API を開いて、カードのボタン表示を1つずつ見ました。押せる状態（Add）のものと、Upgrade to access になっているものに分かれます【実測: n=1, 2026-08-16, Integrations & API画面】。
| 連携先 | 無料プランでの状態 |
|---|---|
| Discord | 使える（Add） |
| Google Chat | 使える（Add） |
| Splunk | 使える（Add） |
| Pushbullet | 使える（Add） |
| Pushover | 使える（Add） |
| Slack | Upgrade to access |
| Telegram | Upgrade to access |
| Webhook | Upgrade to access |
| Mattermost | Upgrade to access |
| MS Teams | Upgrade to access |
| Zapier | Upgrade to access |
| PagerDuty | Upgrade to access |
数えると、使えるのがちょうど5つ、有料限定が7つでした。
この内訳は、事前に想像していたものとかなり違いました。 「無料で5つ使える」と聞いたとき、多くの人はまずSlackを思い浮かべると思います。ところがSlackは有料側です。自分で受け口を作れるWebhookも有料側でした。無料で使えるのは、Discord・Google Chat・Splunk と、スマートフォンのプッシュ通知サービス2つ（Pushbullet・Pushover）です。
チームでSlackを使っている場合、無料プランのUptimeRobotからSlackに通知を流すことはできません。この1点は、無料で始められるかどうかの判断にかなり効くはずです。
なお、モバイルアプリ（Android／iOS）のプッシュ通知は「Download」ボタンでアプリを入れる形で、上の5つとは別枠でした。また、AIアシスタントから自然言語で監視状況を扱うための「MCP」という項目もあり、こちらは無料プランでも「Get Started」を押せる状態でした（実際に接続して動くところまでは試していません）【実測: n=1, 2026-08-16, Integrations & API画面】。
そしてモニターを作る画面の通知先も見ておくと、メール以外は選べません。SMS・音声通話・アプリ内プッシュのチェックボックスはいずれも無効化されていました【実測: n=1, 2026-08-16, モニター作成画面のNotifications and alerts】。
UptimeRobot無料プランのAPIは「読めるが書けない」
料金ページの機能比較表では、Account セクションの「API」の行が Free列も✓ になっています【一次: UptimeRobot 料金ページ 機能比較表, 2026-08-16, https://uptimerobot.com/pricing/】。実際、管理画面の Integrations & API からAPIキーを無料で発行できました【実測: n=1, 2026-08-16, Main API keys】。
そこで、発行したキーで実際にAPIを叩いてみました。
読み取り系は問題なく動きます。アカウント情報を取る getAccountDetails は成功し、monitor_limit が 50、monitor_interval が 5 という値を返しました。モニター一覧を取る getMonitors も成功します【実測: n=1, 2026-08-16, API v2 のレスポンス】。
ところが、モニターを作る newMonitor は拒否されました。
{“stat”:”fail”,”error”:{“type”:”access_denied”,”message”:”You are not allowed to use some settings with your current plan.”}}
エラー文は「現在のプランでは使えない設定が含まれています」と読めるので、特定のパラメータが原因かもしれないと考え、組み合わせを変えて4回試しました【実測: n=1, 2026-08-16, API v2 のレスポンス】。
- 通知先を
alert_contacts=<ID>_0_0の形式で指定 →access_denied - 通知先を
alert_contacts=<ID>だけにする →access_denied - 通知先の指定を外す →
access_denied - 間隔を
interval=600（10分）にする →access_denied
4通りとも同じエラーでした。 URLとモニター種別だけを渡した最小構成でも拒否されます。したがって、無料プランのAPIキーは読み取り専用として扱うのが実態に合っています。
比較表の「API ✓」は嘘ではありませんが、「APIが使える」と読んで自動化を組もうとすると、モニターの作成・更新・削除でつまずきます。モニターの作成は管理画面から手で行う必要があります（この記事のためのテスト用モニターも、そうやって作りました）。
ただし1つ注意を書いておきます。UptimeRobotの公式ドキュメントで「書き込み系APIは有料プラン限定」と明記された箇所は、今回見つけられませんでした。上に書いたのは実際に4通り試して4通りとも拒否されたという事実であって、仕様としてそう決まっていることの確認ではありません。
タイムスタンプが9時間ずれる場所がある
APIを触っていて、もう1つ実務的に困りそうな挙動を見つけました。
アカウント作成の直後に getMonitors を叩くと、モニターの作成時刻が create_datetime という数値（UNIX時間）で返ってきます。この値をそのままUNIX時間として解釈すると 2026-08-16 00:29:56 UTC になりました。しかし、実際にアカウントとモニターを作ったのは 2026-08-16 00:29:56（日本時間）です。9時間ずれています【実測: n=1, 2026-08-16, API getMonitors のレスポンスと実際の操作時刻】。
同じレスポンスの中の registered_at は、ISO形式の文字列で 2026-08-15T15:29:55.000Z と、正しいUTCを返してきます。また、障害ログ（logs）や応答時間（response_times）のタイムスタンプも、UTCとして解釈すると管理画面の表示と一致しました。
つまり、同じAPIレスポンスの中で create_datetime だけが「アカウントのタイムゾーンの壁掛け時計の時刻を、そのままUNIX時間として詰めた値」になっている、という状態です。
このアカウントのタイムゾーン設定を見にいくと、Account details 画面のTimezoneが 「Tokyo, Seoul, Osaka, Sapporo, Yakutsk (GMT+09:00:00)」に自動で設定されていました【実測: n=1, 2026-08-16, Account details画面】。ずれ幅の9時間と一致します。
APIから取った作成日時をそのままログや集計に流すと、日本の環境では9時間先の未来の時刻として記録されます【実測: n=1, 2026-08-16, API getMonitors の create_datetime と実際の操作時刻の差】。他のタイムゾーン設定でも同じずれ方をするかは確認していませんが、少なくとも日本時間に設定されたアカウントでは、create_datetime を扱うときに補正が要ります。
UptimeRobotの通知は、サイトが落ちてから何分で届くか
「監視サービスなのだから、落ちたらすぐ教えてほしい」というのが一番の関心事だと思います。実際に測りました。
自分のサイトに存在しないパスを1つ決めて、そこを監視対象にしました（WordPressが404を返します）。事前に curl で404が返ることを確認しています。
| できごと | 時刻（日本時間） |
|---|---|
| モニターを作成 | 00:33:35 |
| ダウンが確定（インシデント発生） | 00:34:51 |
| アラートメールが届く | 00:34（分単位の記録） |
【実測: n=1, 2026-08-16, API getMonitors の create_datetime／モニター詳細画面のLatest incidents／受信メールのタイムスタンプ】
モニターを作ってからダウンが確定するまで 76秒。ダウン確定の時刻が00:34:51で、メールのタイムスタンプが00:34（分単位）なので、メールの到着は00:34:51〜00:34:59の間、つまり9秒以内に届いたことになります【実測: n=1, 2026-08-16, モニター詳細画面のLatest incidentsと受信メールのタイムスタンプ】。
メールの本文には、判定の理由と監視元の情報が入っていました【実測: n=1, 2026-08-16, アラートメール本文】。
Root cause: HTTP 404 – Not Found
Incident started at: 2026-08-16 00:34:51
Location: Ashburn, USA
リトライを待たずに、1回の失敗でインシデントになりました。 404という明確なエラーだったからかもしれません（タイムアウトや断続的なエラーでも同じ挙動になるかは確認していません）。
ここで注意点が2つあります。
1つ目。この76秒は「モニターを作ってから最初のチェックでダウンを見つけるまで」の時間であって、すでに動いているサイトが途中で落ちたときの検知時間ではありません【実測: n=1, 2026-08-16, モニター作成時刻とインシデント発生時刻の差】。後者はチェック間隔（無料プランは5分が下限）に左右されるので、最悪でその間隔ぶん遅れるはずです。〔2026-08-21追記: 測りました。すぐ下の追記をどうぞ〕
2つ目。復旧したときの通知（Monitor is UP）は、公開時点では測っていませんでした。 〔2026-08-21追記: これも測りました。すぐ下の追記をどうぞ〕
なお、アカウントを作った直後に、件名が「TEST:」で始まるダウン通知とアップ通知が2通届きました。これは通知が正しく届くかを確かめるためのテストメールのようです【実測: n=1, 2026-08-16, 受信メール2通】。
〔2026-08-21追記〕稼働中のサイトが途中で落ちたとき・復旧したときも実測した
公開時に「測っていない」と書いた2つを、公開から5日後に測りました。監視対象には、検証用に用意した別サーバー上のWordPressページを使い、ページの公開状態を切り替えることでHTTP 404（ダウン）と200（復旧）を人為的に発生させています。手元の curl で404／200を確認した時刻を「発生」「復旧」の時刻とし、同じ手順を2周やりました【実測: n=2, 2026-08-21, API getMonitors のlogsとresponse_times・受信メール・手元の時刻記録の突き合わせ】。
| できごと（時刻はJST） | 1周目 | 2周目 |
|---|---|---|
| ダウン発生（curlで404を確認） | 04:07:22 | 04:18:04 |
| 定期チェックが404を踏む（一次検知） | 04:11:00 | 04:22:00 |
| ダウン確定（インシデント発生） | 04:12:05 | 04:23:04 |
| ダウンのアラートメール着信 | 04:12（同じ分） | 04:23（同じ分） |
| 復旧実行（curlで200を確認） | 04:12:38 | 04:23:35 |
| 復旧確定（Monitor is UP） | 04:17:11 | 04:28:09 |
| 復旧のアラートメール着信 | 04:17（同じ分） | 04:28（同じ分） |
分かったことは4つあります。
- 途中で落ちてからダウン確定までは283秒と300秒でした。ダウンがチェック間隔（5分）のどこに落ちるかで変わるので、「最悪でチェック間隔＋約1分」という見積もりが実態に近いです【実測: n=2, 2026-08-21, 発生時刻とインシデント発生時刻の差】。
- ダウン確定は2段階でした。定期チェックが404を踏んだ時点ではインシデントにならず、別の監視拠点からの再確認を経て64〜65秒後に確定します【実測: n=2, 2026-08-21, response_timesのチェック時刻とインシデント発生時刻の差】。メールに書かれた確認元は1周目が Ohio, USA、2周目が N. Virginia, USA で、毎回変わっていました（公開時の実測は Ashburn, USA）。公開時に書いた「モニター作成から76秒でダウン確定」も、この再確認の時間を含んでいたと解釈できます。
- 復旧の通知（Monitor is UP）はちゃんと届きます。 復旧させてから確定まで273秒と274秒。復旧側の確定はチェックから9〜11秒と速く、ダウン側の再確認（64〜65秒）と非対称でした【実測: n=2, 2026-08-21, 同上】。
- 404を返している間も、応答時間グラフには数値が記録されます（404応答の計測値がそのまま載ります）。グラフが動いているからといって正常に動いているとは限りません【実測: n=4, 2026-08-21, response_timesに記録された404応答4件】。
アラートメールの着信は4通とも確定と同じ分内でした（受信箱の表示が分単位のため、秒までは特定できません。公開時の「9秒以内」と矛盾しない結果です）【実測: n=4, 2026-08-21, 受信メールのタイムスタンプ】。
監視しているのは米国のサーバーだった
アラートメールの Location 欄には 「Ashburn, USA」 と書かれていました。モニターの詳細画面の Regions セクションも 「North America」 の1つだけです【実測: n=1, 2026-08-16, アラートメールとモニター詳細画面】。
〔2026-08-21追記〕その後の実測では、ダウンの確認元が Ohio, USA と N. Virginia, USA で毎回変わっていました【実測: n=2, 2026-08-21, アラートメールのLocation欄】。無料プランでは「米国内のどこかから見ている」という理解が実態に近そうです。
前述のとおり、監視する場所を選ぶ「Location-specific monitoring」は有料プランの機能です。つまり無料プランでは、日本のサーバーを日本から監視することはできません。
これは応答時間の数字にも表れます。日本国内のレンタルサーバーに置いた自分のサイトのトップページを、UptimeRobotが記録した応答時間は次のとおりでした【実測: n=3, 2026-08-16, API getMonitors の response_times】。
| 記録時刻 | 応答時間 |
|---|---|
| 00:31 | 692ミリ秒 |
| 00:36 | 841ミリ秒 |
| 00:41 | 893ミリ秒 |
0.7〜0.9秒です【実測: n=3, 2026-08-16, API getMonitors の response_times】。この数字には太平洋を往復するネットワーク遅延が含まれています。日本の読者が同じサイトを開いたときの体感速度とは別物なので、UptimeRobotの応答時間グラフを「サイトの表示速度」として読まないほうがいい、というのが実際に測ってみた感想です。
落ちているか落ちていないかを見るには十分ですが、速度改善の効果測定には向きません。
速度そのものを測りたい場合は、日本国内から直接TTFBを取るほうが実態に近い数字になります。当サイトでは同じ回線・同じ手順で複数のサーバーのTTFBを測っていて、ConoHa WINGのキャッシュを外から測った記録や、安いレンタルサーバーの無料お試しを実際に契約して比べた記録にその数値をまとめています。
チェック間隔は本当に5分ちょうどか
「5分間隔」と書いてあるものが本当に5分ちょうどなのかも見ました。APIの response_times に記録されたタイムスタンプの差を取ります。
取れたサンプルは4つで、結果は 300秒・300秒・300秒・360秒 でした【実測: n=4, 2026-08-16, API getMonitors の response_times】。
4回のうち3回はきっちり5分、1回だけ6分空いていました。 ただしこの数字には注意が必要です。APIが返す response_times のタイムスタンプは分単位に丸められています（秒の位が必ず00になっている）。したがって「360秒」は「記録上6分空いた」という意味で、実際の間隔は301〜419秒のどこかです【実測: n=4, 2026-08-16, API getMonitors の response_times のタイムスタンプ差】。
サンプルが4つでは、これが日常的に起きるゆらぎなのか、たまたまなのかは判断できません【実測: n=4, 2026-08-16, 同上】。「おおむね5分だが、ぴったり5分とは限らない」という程度の理解が実態に近いと思います。
〔2026-08-21追記〕サンプルを追加しました。通常時の間隔は300秒×2で安定していました。またインシデント確定を挟むと、次のチェックは確定時刻から約295秒後に来ており、チェックの基準時刻はインシデントで引き直されるように見えます【実測: n=4, 2026-08-21, API getMonitors の response_times】。
〔2026-08-21 夜の追記〕約1日ぶん・492サンプルで測り直したら、「5分」の実態が見えた
上の4サンプルでは何も言えなかったので、モニターを回したまま約1日放置し、記録を全件取り直しました。3つのモニターで合計492回ぶんの間隔が取れました【実測: n=492, 2026-08-21, API getMonitors の response_times（limit=200）のタイムスタンプ差を全件計算】。
| モニターの状態 | 間隔の中央値 | 最小 | 最大 | 5分ちょうどでなかった割合 | 出典 |
|---|---|---|---|---|---|
| 稼働中（自社サイト・約19時間） | 300秒 | 300秒 | 1,500秒 | 9.5%（199回中19回） | 【実測: n=199, 2026-08-21, response_times のタイムスタンプ差】 |
| 稼働中（別サーバー・約18時間） | 300秒 | 300秒 | 2,760秒 | 9.0%（188回中17回） | 【実測: n=188, 2026-08-21, 同】 |
| ダウン中（404を監視・約24時間） | 900秒 | 600秒 | 3,180秒 | 100%（105回すべて） | 【実測: n=105, 2026-08-21, 同】 |
読み取れたことが2つあります。
1つ目。稼働中でも、10回に1回くらいは5分を超えます。 中央値は300秒ちょうどで公称どおりですが、稼働中の2本とも約9%が300秒を超えていました。実際に出た値は600秒・900秒・1,200秒・1,500秒で、最大では2,760秒（46分）空いた回もありました【実測: n=387, 2026-08-21, 稼働中2モニターの間隔の全分布】。「5分間隔で監視される」は平均的には正しいものの、たまに数十分空くことがあると考えておいたほうが安全です。
2つ目。ダウン中のモニターは、記録の間隔が明らかに違いました。 404を返し続けているモニターでは、300秒ちょうどの記録が105回中1回もなく、中央値は900秒（15分）、最小でも600秒（10分）でした【実測: n=105, 2026-08-21, ダウン中モニターの間隔の全分布】。
ただしこの原因までは特定できていません。(a) UptimeRobot がダウン中のモニターのチェック間隔を実際に延ばしているのか、(b) チェック自体は5分ごとに走っているが、応答時間の記録条件がダウン中は違うのか、今回のデータからは切り分けられませんでした。公式ドキュメントにこの挙動の記載も見つけていません。「ダウン中は記録の間隔が10〜15分に延びる」という観測事実までが、この測定で言えることです【実測: n=105, 2026-08-21, 記録間隔の観測のみ・原因は未特定】。
もし (a) だとすると、落ちたサイトが復旧したことに気づくのは、落ちたことに気づくより遅くなることになります。ただし復旧通知の実測（上の追記）では復旧実行から確定まで273秒・274秒で、少なくともその2回については5分程度で復旧を検知できていました【実測: n=2, 2026-08-21, 復旧実行時刻とUP確定時刻の差】。観測どうしが食い違っているので、サンプルを増やして確かめる必要が残っています。
なお、これらのタイムスタンプは分単位に丸められているため、「300秒」は「記録上5分の差」という意味です。秒単位の精度はこの方法では出せません【実測: n=492, 2026-08-21, response_times のタイムスタンプはすべて秒の位が00】。
無料のステータスページには「検索避けができない」という落とし穴がある
無料プランでもステータスページ（稼働状況の公開ページ）を1つ作れます。実際に作ってみました。
作成画面の設定項目を見ると、次の3つに「Premium feature」が付いていました【実測: n=1, 2026-08-16, ステータスページ作成画面】。
- Custom domain（自分のドメインで公開する）
- Password（パスワードで閲覧制限する）
- Robots meta tag（検索エンジンに載せるかどうかを選ぶ）
3つ目が問題です。作成画面の説明にはこう書かれています。
Meta robots “index” means your website will be visible in search engines. Setting value to “noindex” will hide your Status page in search engines.
つまり無料プランでは「index」で固定され、noindexにできません。
実際に発行されたURLを、ログインしていない環境から確認しました。結果は HTTP 200、HTMLの中には <meta name="robots" content="index"> が入っていました。ステータスページのドメインの robots.txt も確認しましたが、禁止されているのは /api/ だけでした【実測: n=1, 2026-08-16, 発行URLへの匿名アクセス】。
そしてブラウザで開くと、登録したモニターの名前と稼働率が一覧で表示されます。モニター名の初期値は監視先のURLそのものなので、名前を変えないままステータスページに載せると、監視している内部向けのURLがそのまま公開されることになります。
無料で稼働状況を公開できるのは便利ですが、URLを知られたくない管理画面や検証環境を監視対象にしている場合、無料プランのステータスページには載せないほうがいい、というのが実際に作ってみた結論です。ページを非公開にする手段（パスワード）も、検索から隠す手段（noindex）も、どちらも有料側にあります。
UptimeRobotの登録方法でつまずいた点（マジックリンクなら通った）
最後に、登録のときに起きたことも書いておきます。環境に依存する話なので、同じことが誰にでも起きるとは限りません。
https://dashboard.uptimerobot.com/sign-up/ で監視したいURLとメールアドレスを入れて「Register」を押すと、「Finish your account.」という画面に進みます。ここには2つの経路が並んでいます【実測: n=1, 2026-08-16, サインアップ画面】。
- Send me a magic link（メールのリンクでログインする）
- Password（パスワードを決めて登録する）
先に2のパスワード経路を試したところ、条件（8文字以上・数字・大文字・記号）を満たすパスワードを入れても、画面右上に「Error signing up」と出て先に進めませんでした。ブラウザのコンソールを見ると、サインアップのAPIに対する通信がブロックされていました【実測: n=1, 2026-08-16, ブラウザのコンソール出力】。
Access to fetch at ‘https://int-api.uptimerobot.com/internal/user/public/sign-up’ from origin ‘https://dashboard.uptimerobot.com’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check
この画面にはボット判定の仕組み（「Confirm you are a human.」というダイアログ）が組み込まれています。筆者はブラウザ操作を自動化した環境で計測しているため、その判定に引っかかった結果としてリクエストが弾かれ、弾かれた側の応答にCORSの許可ヘッダが無かったためブラウザにはCORSエラーとして見えた、という筋書きが考えられます。通常の手動操作でも同じことが起きるかは確認していません。
一方、1のマジックリンク経路は問題なく通りました。ボタンを押すと1分以内にメールが届き、本文の「Activate my account」を開くと、そのままログイン済みの状態でダッシュボードに着地します。リンクの有効期限は本文に「24時間」と書かれていました【実測: n=1, 2026-08-16, 受信メールの本文】。
登録でつまずいたら、パスワードにこだわらずマジックリンクを試す、というのが今回の回避策でした。
そして、ここが重要なのですが、登録の最初から最後まで、クレジットカードの入力欄は一度も出てきませんでした【実測: n=1, 2026-08-16, 登録の全画面】。料金ページの「No credit card required!」という記載は、そのとおりでした。
結局、UptimeRobot無料プランで何ができるのか（まとめ表）
実機で確かめた範囲を1枚にまとめます。
| 項目 | 無料プランの実際 |
|---|---|
| モニター数 | 50件 |
| チェック間隔 | 5分が下限（5分・30分・1時間・12時間・24時間から選択） |
| モニター種別 | HTTP／Keyword／Ping／Port の4種 |
| 使えないモニター種別 | Heartbeat／DNS／API／UDP |
| SSL・ドメイン期限の監視 | 使えない |
| 監視ロケーションの指定 | 使えない（米国から監視される） |
| 通知先 | メールのみ（SMS・音声通話・アプリプッシュは不可） |
| 連携 | Discord／Google Chat／Splunk／Pushbullet／Pushover の5つ |
| 使えない連携 | Slack／Telegram／Webhook／Mattermost／MS Teams／Zapier／PagerDuty |
| API | 読み取りのみ（作成・更新系は拒否される） |
| ステータスページ | 1つ。検索避け・パスワード・独自ドメインは不可 |
| データ保持 | 3ヶ月（公表値・未検証） |
| クレジットカード | 不要 |
| 管理画面の言語 | 英語のみ（言語切替は見つからず） |
| 【実測: n=1, 2026-08-16, ダッシュボードの各画面】【一次: UptimeRobot 料金ページ, 2026-08-16, https://uptimerobot.com/pricing/】 |
こうして並べると、「個人のサイトが落ちたらメールで知りたい」という用途にはそのまま使えます。50件まで無料というのは実際に大きく、複数のサイトを持っている人には十分な枠です【実測: n=1, 2026-08-16, ダッシュボード右カラムの「Using 1 of 50 monitors.」表示】。
一方で、チームの運用に組み込むには足りない部分がはっきりしています。Slack通知もWebhookも使えず、APIでモニターを作ることもできません。証明書の期限切れも見てくれません。このあたりが必要になった時点が、有料プラン（年払いで月$9のSolo以上）を検討する分かれ目になります【一次: UptimeRobot 料金ページ, 2026-08-16, https://uptimerobot.com/pricing/】。
UptimeRobot無料プランについてよくある質問
Q. 無料で使うのにクレジットカードは必要ですか。
A. 必要ありませんでした。登録からダッシュボードに入るまで、カード情報の入力を求める画面は一度も出ていません【実測: n=1, 2026-08-16, 登録の全画面】。
Q. 管理画面は日本語ですか。
A. 英語のみでした。サインアップ画面・ダッシュボード・モニター作成画面・アカウント設定画面のいずれも英語で、言語を切り替える設定項目は見つけられませんでした【実測: n=1, 2026-08-16, 各画面の表示】。タイムゾーンの設定項目はあり、日本時間が自動で選ばれていました。運営会社は Uptime Robot s. r. o.（スロバキア・ブラチスラバ）と、登録確認メールのフッターに記載されていました【実測: n=1, 2026-08-16, UptimeRobotから届いた登録確認メールのフッター表記】。
Q. 無料プランでSlackに通知できますか。
A. できません。Integrations画面のSlackは「Upgrade to access」でした【実測: n=1, 2026-08-16, Integrations & API画面】。無料で使えるチャット系の連携はDiscordとGoogle Chatです。
Q. 落ちたらどれくらいで気づけますか。
A. 今回の測定では、モニターを作ってから76秒でダウンが確定し、そこから9秒以内にメールが届きました【実測: n=1, 2026-08-16, モニター詳細画面とメールのタイムスタンプ】。〔2026-08-21追記〕稼働中のサイトが途中で落ちたケースも測りました。落ちてからダウン確定まで283秒と300秒（n=2）で、メールは確定と同じ分内に届きました。詳しくは本文の追記をどうぞ。
Q. 応答時間のグラフは、サイトの表示速度として見ていいですか。
A. おすすめしません。無料プランの監視元は米国（Ashburn）で、日本のサーバーに対しては往復のネットワーク遅延が乗ります。今回の実測では、日本国内のサーバーに置いたサイトで692〜893ミリ秒でした【実測: n=3, 2026-08-16, API getMonitors の response_times】。日本の読者の体感速度とは別物です。
Q. 無料プランのAPIで自動化できますか。
A. 読み取りだけです。モニター一覧やアカウント情報は取得できますが、モニターを作る newMonitor はパラメータを4通り変えても拒否されました【実測: n=1, 2026-08-16, API v2のレスポンス】。
Q. ステータスページを作ると検索に出てしまいますか。
A. 無料プランでは検索避けの設定（noindex）が有料機能なので、index のまま固定されます。実際に発行URLを未ログインで開くとHTTP 200で表示され、HTMLに <meta name="robots" content="index"> が入っていました【実測: n=1, 2026-08-16, 発行URLへの匿名アクセス】。実際にインデックスされるかどうかまでは確認していませんが、隠す設定が用意されていないことは確かです。
Q. 料金ページの食い違いは、そのうち直りますか。
A. 分かりません。この記事の記載は2026年8月16日時点で確認したものです。UptimeRobotは2026年に入ってプラン名（Solo／Team／Scale）を含む料金体系を変更しており、今後も変わる可能性があります。修正が確認できたら、その旨をこの記事に追記します。
この記事の測定の限界
正直に書いておきます。
- ほとんどの項目がn=1です。 1つのアカウントで1回ずつ確かめた結果であり、アカウントによって表示が違う可能性（段階的な機能提供やA/Bテスト）は否定できません
- 「Slow response alerts」だけ実機で確認できていません。 6つの食い違いのうち、この1項目は比較表の記載を引用しただけです
- データ保持3ヶ月は公表値です。 3ヶ月後にデータが消えることは確かめていません
- 50件の上限に到達させていません。 51件目を作ろうとしたときに何が起きるかは未確認です【実測: n=1, 2026-08-16, 作成したモニターは2件のみ】
- ~~復旧通知は測っていません~~ →〔2026-08-21追記〕測りました（途中ダウンの検知283秒・300秒／復旧の検知273秒・274秒）。ただしダウンの態様はHTTP 404のみで、タイムアウト・接続不能・5xxのときに確認・再確認の時間が変わるかは未確認です
- チェック間隔のサンプルは計8つ（公開時4つ＋2026-08-21追記時4つ）で、タイムスタンプが分単位に丸められている制約は変わりません
- 登録時のエラーは、自動化環境が原因の可能性があります。 通常の手動操作でも起きるとは限りません
- 計測時間帯は深夜（00:21〜00:50 JST）です。混雑する時間帯では通知の速さが変わる可能性があります
追加で測ったものが出てきたら、この記事に加筆して更新日を改めます。
本記事で検証したサービスへのリンク
下のリンクは当サイトの紹介リンクです。無料での登録・利用では報酬は発生しません。このリンクを経由して有料プランが契約された場合に、当サイトへ紹介報酬が支払われます。報酬は継続課金にも及ぶ条件（提供元の公式説明で「20% LIFETIME (recurring) commission」と記載）であるため、読者の方が契約を続けている間、当サイトに報酬が発生し続けることがあります【一次: UptimeRobot アフィリエイトプログラム案内, 2026-08-16, https://uptimerobot.com/affiliate-program/】。この点も含めて開示しておきます。報酬の有無によって、本記事の測定結果や記述を変えることはしていません。
紹介リンクを使いたくない場合は、検索などから公式サイトを直接開いてください。提供される内容もプランの価格も変わりません。
なお本記事で扱ったとおり、無料プランの範囲で試すだけであれば料金は発生しません。クレジットカードの登録も不要です。
当サイトの広告に関する方針は広告・PR表記に関するポリシーに記載しています。
この記事の測定条件・証跡の詳細は運営者情報・編集方針に記載の方針に従っています。広告表示についての方針は広告・PR表記に関するポリシーをご覧ください。
