Core Web Vitalsに標準付属の稼働監視

サイトや決済画面の停止を検知し、平常時のサーバー応答速度も把握できます。

モニターを追加

全プランおよび無料トライアルに含まれています。

Trusted by market leaders · Client results

my work featured on web.devdpg medianina carevpnwhowhatwearsnvcomparealeteiaadevintaebayperionmarktplaatsworkivahappyhorizonmonarchnestleharvarderasmusmcsaturnloopearplugsfotocasakpn

サイトは正常に見えるのに、注文が止まっている

サーバーが応答しなくなっても、CDNはキャッシュされたトップページを返し続けます。あるいは、リリースによって他のページは正常なのに決済画面だけが壊れることもあります。顧客から「決済できない」と問い合わせのメールが届くまで、誰も気づきません。

CoreDashは、Core Web Vitalsと同じプロジェクト内でこの両方を監視します。

サイト停止時はメールとSlackで通知

サイトが停止したときや、ページが想定外のステータスを返したときは、メールとSlackで通知が届きます。復旧時にも同様に通知されます。トップページや決済画面など重要なページを登録すれば、CoreDashが各ページを30分ごとにチェックします。

2台の異なるサーバーから2回連続でチェックに失敗して初めて、モニターがDownになります。一時的なネットワークの揺らぎで起こされる心配はありません。

CoreDashの稼働監視:1件がDown、1件がFailing、1件がファイアウォールでBlocked、1件がUnexpected status、残りはUp、直近7日間の稼働率を表示

監視対象のすべてのサイトとページを1つのリストに集約。直近7日間の稼働率と、2週間以内に期限が切れる証明書を確認できます。

CDNが隠してしまう障害を検知

サーバーがダウンしていても、CDNはキャッシュされたページを返し続けます。トップページは表示されますが、ログイン中のユーザーやカート画面、キャッシュされていないすべてのページでエラーが発生します。それでもCoreDashはサイトをDownと判定できます。モニターの追加時や編集時に「Advanced」でサーバーのIPアドレスを入力しておけば、毎回のチェックでCDNを迂回し、サーバー本体にも直接問い合わせます。

CDNがキャッシュページを配信し続けている中、サーバー本体が応答しないためDownと判定されているモニター

訪問者の待ち時間のうち、どれだけをサーバーが占めているか

この例では、訪問者の待ち時間の約半分をサーバーが占めています。CoreDashは、毎回のチェックの応答時間を、実際の訪問者が体験しているp75のTTFBと並べて表示します。チェッカー側の計測値が毎晩ピークを迎えながら約950 msであるのに対し、訪問者のTTFBは1.92秒です。

サーバーが応答するまで、最大の画像や見出しは表示されません。この状況でLCPを改善するには、まずサーバーから着手する必要があります。

毎晩ピークを迎え約950 msで推移する7日間のサーバー応答時間と、訪問者のTTFB 1.92秒の比較

直近のリリースで壊れた決済画面を検知

リリース後、トップページは正常に応答していても、決済画面で「ページが見つかりません」と表示されることがあります。トップページを監視しているモニターは、この異常を検知できません。

この例では、決済画面に個別のモニターを設定しています。5日間は正常に稼働していましたが、2日前のリリース以降は404を返しており、CoreDashはこれをUnexpected statusと判定しています。この場合もメールとSlackに通知が送信され、決済画面が復旧した際にも再度通知が届きます。

5日間ステータス200を返したあと、2日前のリリース以降404を返している決済画面

ファイアウォールによる誤アラートを防ぎ、証明書の期限切れも2週間前に検知

チェッカーがファイアウォールに遮断されても、障害アラートが誤作動することはありません。モニターにはBlockedと表示され、対処方法へのリンクが案内されます。ダウンタイムとしてカウントされることもありません。

モニター一覧では、14日以内に期限が切れる証明書も集計されます。更新を忘れていた場合も、ブラウザが訪問者に警告を出し始める2週間前に把握できます。

Blockedと表示されたモニター:ファイアウォールがチェッカーに403を返しており、対処方法へのリンクを表示

19:50にクラッシュが発生したあとの流れ

19:50にサーバーが応答を停止します。20:00に1台目のサーバーで応答が得られず、モニターはFailingになります。この時点ではまだ通知は送信されません。30分後、2台目のサーバーからも応答が得られません。ここでモニターがDownになり、メールとSlackの通知が送信されます。

再び応答が得られた最初のチェックで、モニターはUpになり、同様に復旧通知が送信されます。サーバーが停止したタイミングによって、30分から60分後に通知が届きます。

チームが普段開いているプロジェクトで稼働監視

すべてのモニターはCoreDashプロジェクトに属しており、プロジェクトの参加者全員が、同じサイトのLCP、INP、CLSと並べて確認できます。契約中のプランにも、トライアルにも標準で含まれています。モバイルのLCPが悪化した理由を質問するのと同じチャットで、Claudeに「今週サイトはダウンした?」と尋ねることもできます。ClaudeをCoreDashと連携。

専用の稼働監視ツールが必要になるケース

CoreDashは単一リージョンの2台のサーバーから30分ごとにチェックを行い、メールとSlackで通知します。チェックとチェックの間の短時間の障害は見逃される可能性があり、公開ステータスページやSMS通知の機能はありません。多数の国から毎分チェックを行う必要があるなら、専用の稼働監視ツールにお金を払う価値があります。

サイトや決済画面が正常に稼働しているか、サーバーがどれだけ速く応答しているかを把握するだけなら、専用ツールは不要です。追加費用なしで、すでにCoreDashプロジェクトに含まれています。

よくある質問

稼働監視に追加料金はかかりますか?

いいえ、かかりません。すべてのプランおよび無料トライアルに含まれており、プロジェクトが継続する限りモニターは稼働し続けます。詳細は料金プランをご確認ください。

サイトはどのくらいの頻度でチェックされますか?

1時間に2回です。一方のサーバーが毎正時(00分)に、もう一方が30分にチェックします。

アラートはどこに送信されますか?

プロジェクトに参加しているメンバーのメールアドレスに送信されます。また、プロジェクトにSlackを連携している場合はSlackにも通知されます。

ファイアウォールの設定変更は必要ですか?

チェッカーがブロックされる場合のみ必要です。毎回のチェックではCoreDashのユーザーエージェントとプロジェクトのボットトークンが送信されるため、ファイアウォールのルールでいずれかを許可できます。CoreDashの通信を許可する方法。

モニターは何件まで追加できますか?

1プロジェクトにつき最大25件までです。1つのモニターがチェックするURLは1つです。トップページ、決済画面、ログイン画面を監視する場合は3つのモニターになります。

稼働監視を利用するにはサイトにCoreDashのスクリプトが必要ですか?

いいえ、不要です。モニターに必要なのはCoreDashプロジェクトだけで、スクリプトの有無にかかわらずチェックは実行されます。ただし、訪問者のTTFBを表示するカードは、スクリプトから実ユーザーのデータが届くまで空のままになります。

まずは売上を生み出すページから

CoreDashプロジェクトで「Uptime」を開き、決済画面を追加してください。次の毎正時(00分)または30分に初回のチェックが実行されます。

モニターを追加

CoreDashアカウントをお持ちでない場合は、無料トライアルをお試しください。稼働監視も含まれています。