「Webサイトの稼働率が99.9％なら、何分まで停止してよいのか」「月に1時間ダウンしたら、稼働率は何％になるのか」。数字で確認したいときは、まず計算期間を決め、その期間の総時間から停止時間を引きます。稼働率99.9％なら、30日間の停止許容時間は43.2分（43分12秒）です。1年間を365日として計算すると、8時間45分36秒になります。
ただし、この値は「期間中のどの瞬間も監視できていて、停止していた時間を把握できる」という時間ベースの計算例です。5分ごとや1日2回のHTTPチェックで得られる監視チェックの成功率を、そのまま24時間365日の実稼働率と呼ぶことはできません。監視していない時間に起きた短い停止は、記録されない可能性があります。
この記事では、Webサイト運営担当者が電卓や表計算ソフトで再現できる計算式、99％〜99.999％の比較表、停止時間を集計する具体例、監視履歴から報告書を作る際の注意点を順番に解説します。死活監視の方式そのものを知りたい場合は、先に死活監視の基本とHTTP・PING監視の違いをご確認ください。本記事は、数値の計算と読み方に絞っています。
Webサイトの稼働率とは？計算前に知りたい基本
稼働率は、対象のWebサイトが決められた期間のうち、正常に利用できた割合を示す指標です。数字を出す前に「何を正常とするか」「何日間を対象とするか」「どう観測したか」をそろえる必要があります。基準が異なる数字を並べても、正しい比較にはなりません。
時間ベースの稼働率の計算式
サイトが利用できた時間と停止した時間を用いる場合、基本式は稼働率（％）＝（対象期間の総時間－停止時間）÷対象期間の総時間×100です。反対に、目標稼働率から停止を許容できる時間を求めることもできます。
たとえば30日間の総時間は30日×24時間×60分＝43,200分です。この間に30分停止した場合、（43,200－30）÷43,200×100＝約99.9306％となります。稼働率99.9％という目標と比較するなら、少なくともこの計算期間では目標を満たしたことになります。
停止許容時間を逆算する式は、対象期間の総時間×（1－目標稼働率÷100）です。99.9％は小数で0.999、停止に使える割合は0.001です。43,200分×0.001＝43.2分と求められます。
「正常に使える状態」を先に決める
HTTPで応答が返っただけでは、利用者にとって正常とは限りません。たとえばトップページは表示されても、問い合わせフォームが送れない、決済が進まない、ログイン後にエラーになるという状態が考えられます。逆に、ある一部のページだけが不調でも、サイト全体が完全停止しているとは限りません。
実務では「トップページに正常応答がある」「予約受付が完了する」「会員がログインできる」など、サービスにとって重要な機能を基準にします。トップページの稼働率なのか、Webサイト全体の業務継続率なのかを、計算結果に添えておきましょう。基準が分からない99.9％という数字だけでは、改善の判断材料として不十分です。
時間ベースとリクエストベースは別の指標
時間ベースは、一定期間のうち何分間利用できたかを測ります。一方、リクエストベースでは、処理されたリクエスト総数のうち成功した数の割合を測ります。たとえば10,000件中9,990件のリクエストが成功すれば、成功率は99.9％です。この計算だけでは停止が合計何分続いたかは分かりません。
アクセスが多い昼間と少ない深夜では、同じ1分間の障害でも失敗するリクエスト数が変わります。また、一部の利用者だけに影響する障害は、時間ベースの「全面停止／正常」では実態を表しにくいことがあります。GoogleのSRE資料でも、時間で測る可用性と成功したリクエストの割合で測る可用性を区別しています。目的に合う指標を選び、名前を混同しないことが重要です。
稼働率99.9％は何分停止できる？1日・1週間・1か月・1年の早見表
99.9％の稼働率を目標にする場合、停止に充てられるのは計算期間全体の0.1％です。時間を分へ換算すると、1日・7日間・28日間・30日間・31日間・365日間で許容時間が異なることが分かります。
| 計算期間 | 期間の総時間 | 99.9％での停止許容時間 |
|---|---|---|
| 1日（24時間） | 1,440分 | 1分26.4秒 |
| 7日間 | 10,080分 | 10分4.8秒 |
| 28日間 | 40,320分 | 40分19.2秒 |
| 30日間 | 43,200分 | 43分12秒 |
| 31日間 | 44,640分 | 44分38.4秒 |
| 365日間 | 525,600分 | 8時間45分36秒 |
この表は、期間中の予定停止を特別に除外せず、全時間を分母とした単純計算です。30日間で99.9％なら43.2分、31日間なら44.64分となり、たった1日の違いでも基準は変わります。年間の8時間45分36秒という数字も、365日の平年を仮定した値です。
「ひと月」という表現は30日固定を意味しません。暦上の2月・4月・7月では対象分数が違います。月次報告を作るなら、まず集計の開始日時と終了日時を明記し、その範囲の正確な分数を使ってください。一般的なSREの早見表に掲載された「1か月」の値は、便宜的な30日換算である場合があります。
30日間で99.9％になる計算を再現する
30日間を分単位で計算すると、43,200分×（100－99.9）÷100＝43.2分です。43.2分を分と秒に直すには、小数部分の0.2分に60を掛けます。0.2×60＝12秒なので43分12秒となります。
反対に43.2分の停止が発生したとすれば、稼働できた時間は43,200－43.2＝43,156.8分です。43,156.8÷43,200×100＝99.9％と確認できます。往復で計算して一致するかを確認すると、電卓への入力ミスに気づきやすくなります。
うるう年や営業日だけの計算ではどうなる？
2028年のようなうるう年は年間366日です。366日×1,440分×0.001＝527.04分となり、99.9％の停止許容時間は8時間47分2.4秒です。年次目標では、対象年が365日なのか366日なのかを明示しましょう。
社内システムのように「平日の9時から18時だけを対象にする」という考え方もあります。ただし、一般公開のWebサイトでは営業時間外にも閲覧やフォーム送信が発生します。ユーザーがいつ利用するかと、契約上の評価時間が一致するとは限りません。営業日ベースで計算する場合は、24時間ベースの値と同じ「稼働率」とだけ書かず、対象時間を必ず併記します。
99％・99.9％・99.99％の違いを停止時間で比較する
稼働率の数字は、9が一つ増えるだけでも、許容される停止時間が大幅に短くなります。運用目標を決めるときは、パーセンテージを眺めるだけでなく、実際に何分の停止を意味するかを比較することが重要です。
| 目標稼働率 | 30日間で許容できる停止 | 365日間で許容できる停止 |
|---|---|---|
| 99％ | 7時間12分 | 3日15時間36分 |
| 99.5％ | 3時間36分 | 1日19時間48分 |
| 99.9％ | 43分12秒 | 8時間45分36秒 |
| 99.95％ | 21分36秒 | 4時間22分48秒 |
| 99.99％ | 4分19.2秒 | 52分33.6秒 |
| 99.999％ | 25.92秒 | 5分15.36秒 |
99.9％と99.99％を30日間で比べると、停止許容時間は43分12秒と4分19.2秒です。後者は前者の10分の1しか停止できません。さらに99.999％を目標にすると30日で約26秒です。障害の発見だけでなく、自動的な切り替えや冗長化、変更作業の安全性も重要になってきます。
「スリーナイン」「フォーナイン」の読み方
99.9％は小数点以下に9が一つ続くことから「スリーナイン」、99.99％は「フォーナイン」、99.999％は「ファイブナイン」と呼ばれることがあります。呼び名よりも重要なのは、どの機能を何日間の窓で評価し、どの状態を停止として扱うかです。
宣伝資料の「99.9％稼働」という数字と、契約上のSLAで保証される数字は同じ意味とは限りません。目標値なのか実績値なのか、対象がインフラ単体なのか利用者向けサイト全体なのかも確認しましょう。
目標が高いほど費用と運用は変わる
99.99％以上を目指す場合、単純に監視間隔を短くするだけでは達成できません。停止そのものを減らす設計、復旧を速くする仕組み、設定変更の検証、障害時の対応体制などが必要です。たとえばECサイトの決済機能と社内の参照専用ページでは、数分の停止がもたらす影響が異なります。
まず「何分止まると利用者にどんな影響があるか」を整理し、業務への影響、費用、体制から目標値を決める方が現実的です。目標を高く設定すること自体が品質を保証するわけではありません。
実際の停止記録から月間稼働率を計算する手順
実績値を出す場合は、まず障害の開始・終了を同じタイムゾーンで整理します。停止時間を単純に足し合わせる前に、重複する障害や集計期間からはみ出す時間を調整することが大切です。ここでは30日間の計算例を使います。
手順1：計算期間と停止の判定条件を固定する
例として、2026年9月1日0時から10月1日0時の直前までを、JSTの30日間として考えます。対象は「外部の利用者が指定URLのページを正常に表示できる状態」とします。DNS障害やHTTPの継続的な失敗など、利用者が利用できなかったと判断する事象を計上します。
計測地点が国内だけなのか複数地域なのか、何秒以上応答がなければ失敗とするかも記録しておきましょう。今回は計算の練習として、開始時刻と終了時刻が別の証拠によって確認できたものと仮定します。監視のチェック時刻だけから、秒単位の真の停止開始・復旧時刻を確定したものではありません。
手順2：各障害の継続時間を求める
障害Aは9月5日10時00分から10時18分までの18分、障害Bは9月12日15時10分から15時34分までの24分だったとします。二つの停止が重複していなければ、停止時間は18＋24＝42分です。期間の総時間は43,200分で変わりません。
| 障害 | 開始・終了（JST） | 停止時間 |
|---|---|---|
| A | 9月5日 10:00〜10:18 | 18分 |
| B | 9月12日 15:10〜15:34 | 24分 |
| 合計 | 重複なし | 42分 |
一つの障害の最中に別の監視項目も失敗していた場合、同じサービス全面停止を二重に加算してはいけません。たとえばAが10:00〜10:18、別のログが10:05〜10:13を示していても、同じ対象の停止区間なら合計は18分です。監視URLが異なる場合は、両者が本当に同じサービス全体の停止かも判定します。
手順3：公式に当てはめ、目標との差を出す
実績稼働率は（43,200－42）÷43,200×100＝99.902777…％で、小数第4位を四捨五入して99.903％と表示できます。30日間・99.9％の停止許容時間43.2分と比べると、残り1.2分、つまり1分12秒の余裕があります。
同じ月にさらに3分の停止が起きると、累計45分です。この場合は（43,200－45）÷43,200×100＝99.895833…％になり、99.9％の目標を下回ります。わずかな差に見えても、集計期間を固定すると達成・未達が明確になります。
手順4：重複・期間外・観測できない区間を整理する
月末23時50分に停止し翌月0時20分に復旧した障害は、当月の集計には月末までの10分だけを含めます。翌月の計算には残り20分を含めます。月をまたぐ停止を全体として一つの事故記録に保持しつつ、集計期間ごとに切り出して加算するのが基本です。
また、監視基盤そのものが停止して計測できなかった時間を、勝手にサイト正常として埋めないでください。「正常」「異常」「未計測」の区分を持ち、未計測をどう扱うかを別途定義する必要があります。未計測を含む値を概算として出すときは、実測値とは明確に区別します。
Excel・Googleスプレッドシートで稼働率を計算する方法
毎月同じ方法で計算するなら、表計算ソフトに対象期間と障害の開始・終了時刻を入力し、停止時間の合計を自動計算すると便利です。ここでは時間ベースの値を、誰でも見直せる形で残す方法を紹介します。
期間・停止時間・稼働率の入力例
A2に開始日時、B2に終了日時、C2に停止時間（分）を入力する場合、日時が通常の表計算用の日付時刻として認識されていれば、=(B2-A2)*1440で停止分数を計算できます。1日は1という内部単位で扱われるため、60分×24時間の1,440を掛けます。
たとえばA2が「2026/9/5 10:00」、B2が「2026/9/5 10:18」ならC2は18になります。複数の障害についてC列を合計し、D2に月の総分数43,200、E2に停止合計42を置けば、F2の式=(D2-E2)/D2*100で99.902777…が得られます。セルをパーセント形式にするなら、=(D2-E2)/D2を入力して％表示にします。
計算式をコピーするときは、期間を表すセルを絶対参照にするなど、参照先がずれないよう注意してください。停止時間に負の値がないか、開始と終了が逆になっていないか、同じ障害が複数行に登録されていないかも確認します。
小数点の丸め方と表示のルール
99.902777…％を小数第2位まで表示すると99.90％です。一方、99.895833…％も小数第2位までに丸めると99.90％と表示される場合があります。これでは目標達成と未達の違いが見えなくなるため、判定は丸める前の元の数値で行うことが重要です。
社内報告なら、稼働率は小数第3位または第4位まで、停止時間は分・秒で併記すると分かりやすくなります。ただし表示桁数が細かいからといって、計測の精度が高いとは限りません。5分ごとの監視で得た推定値に秒単位の精度があるかのような説明は避けましょう。
表計算だけでは処理しにくい重複区間
2行以上の停止時間が重なるときは、単純なSUMでは実停止時間が過大になります。障害を時刻順に並べて重なりを統合し、連続した区間として扱ってから分数を計算してください。障害が少ない場合は目視で照合できますが、サイト数が多い場合はログの整形が必要です。
障害ごとに「対象サービス」「検知時刻」「障害開始の推定時刻」「復旧確認時刻」「観測根拠」「備考」を残しておくと、後から合計時間の意味を説明できます。URL別の失敗をすべて同一のサイト停止として足し合わせると、実態より悪い数値になりやすい点にも気をつけてください。
停止許容時間をエラー予算として管理する考え方
停止許容時間を「あと何分の失敗を受け入れられるか」という予算として見る考え方があります。SREで使われるエラー予算は、目標とするサービスレベルに対して許容される失敗の範囲を示すものです。時間ベースで管理するなら、月初の残り時間から障害の実績を差し引きます。
30日間・99.9％なら43分12秒が出発点
30日間の目標が99.9％の場合、初期予算は43分12秒です。先ほどの例で合計42分停止した時点では、残り1分12秒しかありません。別の1分30秒の停止が発生すれば、合計43分30秒となって目標未達です。見込みではなく、確定した観測根拠に応じて実績を更新します。
障害が月の前半に集中した場合と後半に集中した場合では、同じ合計時間でも運用上の判断が変わります。前半に予算を大きく使ってしまったら、大きな設定変更の実施を慎重にする、復旧手順を改善するなど、次の障害を防ぐための行動につなげられます。
目標稼働率とSLAを混同しない
自社の運用目標として定めるSLOと、サービス提供者と利用者の間で定めるSLAには違いがあります。一般的な目標の計算式が同じでも、SLAでは「どの状態を利用不可とするか」「何が除外されるか」「返金・サービスクレジットの条件は何か」などが個別に決められます。
したがって、この記事の43分12秒をそのまま契約上の免責範囲や補償判断に使うことはできません。クラウドサービスの可用性保証を読む場合も、利用者から見たWebサイト全体の稼働率と、提供事業者の特定サービスのSLAを同一視しないようにしましょう。
監視結果の成功率と実際の稼働率が一致しない理由
HTTP監視はサイトの状態を把握する有用な手段ですが、一定間隔のチェックは連続観測とは異なります。とくに稼働率を対外的な数値として示す場合は、「監視結果から何が言えるか」と「まだ確認できないこと」を分ける必要があります。
監視間隔の間に起きる短時間の停止
5分間隔で9時00分、9時05分、9時10分にチェックするとします。9時01分にサイトが停止し9時04分に復旧していれば、チェックは3回とも成功する可能性があります。実際には約3分停止していますが、監視履歴には失敗が一件も残りません。
逆に9時05分のチェックだけ失敗し、9時10分に成功した場合でも、停止がぴったり5分続いたとは限りません。障害がいつ始まったか、いつ復旧したかは、その前後の情報でしか絞り込めないためです。チェック結果を機械的に「1回の失敗＝5分停止」と換算すると誤差が生じます。
チェック成功率100％が24時間稼働の証明にならない
1日2回だけ監視して両方成功した場合、チェック成功率は2÷2×100＝100％です。しかし、その間にサイトが3時間停止していた可能性を否定できません。監視回数が少ない場合ほど、計測できていない時間の扱いが重要になります。
したがって、監視画面に「チェック成功率100％」と表示されていても、「24時間の実稼働率100％」へ自動的に読み替えるべきではありません。監視サービスを使うときは、成功率の算出対象、未計測の扱い、障害の判定条件を確認してください。
外部監視・サーバーログ・利用者影響を組み合わせる
外部のHTTP監視は、指定した地点からサイトにアクセスできるかを確認します。サーバーやアプリケーションのログは内部の処理失敗を調べるのに役立ち、利用者からの問い合わせは特定機能の不具合を発見するきっかけになります。それぞれ得意とする観測範囲が違います。
重要なサイトでは、外部監視、アプリケーションのエラーログ、主要機能のテストを照合すると、単一の監視だけでは見逃す問題を補いやすくなります。監視システム自体の停止や通信経路の不調と、対象サイト側の障害を切り分けることもできます。
部分障害と地域差があるときの評価
ある地域からは表示できても、別の地域からは接続できないことがあります。また、サイトの一覧ページは表示できても、一部の利用者だけがログインできない場合もあります。このような部分障害を「サイト全体が100％停止」とみなすのか、影響を受けた機能・利用者の割合で評価するのかによって数値は変わります。
単純な時間ベースの計算は、停止区間が明確なサービスに向いています。一部の機能だけに影響する状況を詳細に評価するには、正常に完了したリクエストの割合など別の指標が適切な場合があります。目的に合わせて複数の数字を使い分けましょう。
計画メンテナンスや営業時間外の停止は含めるべき？
定期メンテナンスの時間を稼働率の分母から除くかどうかは、採用する基準や契約条件によります。利用者にとっては、予定されたメンテナンスでも実際にはサービスを使えない時間です。数値を比較する前に、計画停止の取り扱いを明確にしてください。
予定停止を含む稼働率と除外する稼働率
30日間で予告済みのメンテナンスが60分、予期しない障害が20分あった場合を考えます。すべてを停止時間として含めると、停止合計は80分で稼働率は約99.815％です。もし特定の契約ルールで予定停止を集計対象時間から除外するなら、分母や停止計上方法が変わります。
この二つの数値をどちらも単に「月間稼働率」と呼ぶと比較を誤ります。「計画停止を含む実績」「契約上の除外条件を適用した実績」など、計算条件を数値の近くに示すことが大切です。クラウド事業者の公表するSLAについても、サービスごとの定義を確認しましょう。
無理な除外がユーザー体験を見えなくする
事前告知していたからといって、利用者の不便がなくなるわけではありません。日中のメンテナンスが予約や購入に影響したのなら、運用改善の対象になります。法的・契約上の算定とは別に、利用者が実際に使えなかった時間を内部指標として記録することをおすすめします。
予定停止の有無、時間帯、影響した機能、周知の有無をセットで記録すれば、単なる稼働率の数字だけでは分からない改善点が見えてきます。高い稼働率を維持することと、ユーザーが必要なときに利用できることは、似ていますが完全には同じではありません。
サイト運営で稼働率を報告するときのチェックリスト
稼働率の計算ができたら、次は「その数字を他の担当者が同じ方法で再現できるか」を確認します。報告書には計算条件、元となる事実、計測の限界を残すことが大切です。以下の項目を揃えると、数か月後の比較にも使いやすくなります。
報告書に最低限入れたい項目
報告対象のサイト名・URL、対象期間、タイムゾーン、監視方法、正常判定の条件、実際の停止件数と合計時間、未計測区間、実績値、目標値との差を記載します。監視対象URLを変えたり、チェック間隔を変えたりした月は、過去の月との単純比較ができない場合があるため注記してください。
また、障害原因が判明しているか、再発防止策を実施したか、利用者影響がどの範囲だったかも、必要な範囲で追記します。報告の主役はパーセンテージだけでなく、安定して利用できる状態を維持するための判断材料です。
数字だけでなく障害の分布を確認する
同じ40分間の停止でも、40分の障害が1回起きたのか、2分の障害が20回起きたのかでは運用上の課題が違います。前者では復旧に時間がかかった原因、後者では断続的な通信不良や設定の不安定さが問題かもしれません。
障害件数、最長停止時間、発生した曜日や時間帯、復旧までの時間などを併せて確認すると、数値の背後にある傾向を発見できます。ただし、チェック間隔より短い停止を完全に把握できるわけではありません。記録から分かることと推測を分けて記述しましょう。
複数サイトの平均稼働率に注意する
5サイトの稼働率がそれぞれ99.9％、99.9％、99.9％、99.9％、95％だった場合、単純平均は98.92％です。しかし、この値だけでは利用者数や重要度、サイトごとの計算期間、計測方法は分かりません。売上を担うサイトとテスト用サイトを同列に扱うことが適切でない場合があります。
まずはサイト別に実績を示し、その後で必要に応じて目的に合う集計方法を検討してください。異なる計算期間や監視方式の割合を無条件に平均すると、比較できない数値を混ぜることになりかねません。
目標稼働率は何％に設定する？用途別の考え方
稼働率の目標は、高ければ高いほど良いと単純に決められるものではありません。停止が発生した場合の利用者影響、必要な復旧速度、システムの構成と保守費用から考えます。Webサイトの種類ごとに「何が使えないと困るか」を整理することから始めましょう。
企業サイト・採用サイト・情報メディア
企業サイトや採用サイトは、問い合わせや応募の機会を逃さないことが大切です。たとえば問い合わせフォームの停止が長引けば、トップページが表示できていても事業機会への影響が生じます。企業サイト全体だけでなく、問い合わせ先や応募先の利用可否を別途確認する考え方が役立ちます。
目標を決めるときは、障害に気づくまでの時間と復旧するまでの時間を分けて考えます。監視が短い間隔であっても、修正担当者が不在なら復旧は遅れます。小規模な運営体制なら、まず確実に連絡がつく仕組みと手順を整える方が効果的な場合があります。
ECサイト・予約サイト・ログイン必須サービス
ECサイトや予約サイトでは、利用者が「最後まで取引を完了できるか」が重要です。Webサーバーから200番台のHTTP応答が返っていても、決済機能だけが不調であれば実際のサービス品質は下がります。監視URLの設計に加えて、重要な業務処理の確認方法を検討しましょう。
売上への影響が大きいサービスでは、稼働率を高める構成、障害時の切り戻し手順、変更作業の検証、利用者への案内体制などを総合的に考えます。稼働率99.99％という目標を掲げるだけで、業務上必要な信頼性が自動的に得られるわけではありません。
稼働率だけでなく復旧力も見る
停止時間が短ければ同じ稼働率でも、繰り返し発生する小さな不具合に利用者が不安を感じる場合があります。また、停止が起きてから原因調査を始めるまでに長い時間がかかると、復旧が遅れやすくなります。
監視の実行回数、失敗の連続回数、担当者が気づいた時刻、復旧を確認した時刻を振り返りましょう。稼働率は運用品質の重要な一面ですが、実際の使いやすさや復旧の速さまで一つの数字だけで表すものではありません。
エンリンクの監視履歴を稼働状況の確認に役立てる
稼働率の計算には観測データが必要です。エンリンクでは登録したWebサイトへのHTTP/HTTPSチェックの結果、ステータスコード、応答時間などを確認でき、サイトごとの監視履歴を振り返れます。ただしチェック結果を利用者が体験した真の停止時間へ自動変換できると断定するものではありません。
無料プランで確認できること
エンリンクの無料プランは最大5サイトまで登録でき、定期監視は1日2回です。サイト一覧や監視履歴から、取得したチェック結果や異常の手掛かりを確認する入口として利用できます。無料プランでは24時間の連続稼働を証明できるわけではないことにも注意してください。
チェック回数や成功率を稼働状況の参考として確認し、より詳しい調査が必要なときは監視対象サイトのログや障害記録と照合しましょう。提供中の機能についてはエンリンクの機能一覧をご確認ください。
監視対象と間隔を用途に応じて選ぶ
複数サイトの状態をまとめて確認したい場合は、サイトごとのURL、監視の間隔、最近の失敗状況を整理すると日常運用がしやすくなります。エンリンクの有料プランは、契約プランに応じて15分・5分・1分の最短監視間隔を選べますが、監視時刻や障害検知までの時間を保証するものではありません。
現行の登録可能サイト数や監視頻度などの条件は料金プランに掲載しています。まずは無料で利用イメージを確認したい場合は、エンリンクの無料アカウント登録から始められます。登録しただけで停止時間がすべて自動計算されるという説明は避け、取得できた記録を実際の運用に役立てることを意識しましょう。
Webサイトの稼働率についてよくある質問
ここまでの計算式と注意点を、実務でよく迷う質問に沿って整理します。数値を扱うときは、常に対象期間と計測条件を合わせて確認してください。
稼働率99.9％なら1か月に何分停止できますか？
30日間として計算するなら43分12秒です。ただし28日間なら40分19.2秒、31日間なら44分38.4秒となります。契約上のSLAでは除外条件が異なる可能性もあるため、単純計算と契約上の基準は分けて確認してください。
99.99％なら30日間で何分ですか？
4.32分、つまり4分19.2秒です。99.9％の43分12秒と比べると10分の1です。わずかな停止時間しか許容されないため、目標達成には監視だけでなくシステム設計と復旧体制が重要になります。
1時間停止した場合の月間稼働率は何％ですか？
30日間のうち60分停止したと仮定すると、（43,200－60）÷43,200×100＝約99.8611％です。99.9％の目標には届きません。1か月を28日間や31日間とする場合は総分数が変わるので、同じ1時間停止でも稼働率は少し異なります。
監視ツールで正常と表示されれば稼働率は100％ですか？
いいえ。正常表示は、その監視が確認した時点・対象・判定条件についての結果です。監視間隔の間に起きた障害や、監視対象外の機能の不具合まで否定するものではありません。チェック成功率と実時間ベースの稼働率を分けて読むことが重要です。
稼働率の計算にはメンテナンス時間を含めますか？
一般的な時間ベースの可用性を厳密に測るなら、利用者が使えない予定停止も影響します。一方、特定のSLAでは計画停止などを除外する条件が定められる場合があります。両方を扱うなら、計算条件と数字の名称を明記してください。
停止時間が分からない場合も稼働率を計算できますか？
正確な停止区間が分からない場合、厳密な時間ベースの稼働率を確定することはできません。監視チェックの成功率や、確認できた停止区間の合計といった別の指標を報告し、推定値であることを示してください。観測できていない時間をすべて正常だったことにしないようにしましょう。
サイトが複数あるときは稼働率を平均すればよいですか？
単純平均は算出できますが、サイトの用途、利用者数、監視方法、対象期間が異なると解釈を誤ることがあります。まず各サイトの稼働率と停止時間を個別に示し、横断集計の目的を決めたうえで集計方法を選ぶことをおすすめします。
まとめ：99.9％は30日で43分12秒。計算条件までセットで伝える
Webサイトの稼働率は、対象期間の総時間から停止時間を引き、その割合を求めることで計算できます。30日間で99.9％を目指すなら、停止許容時間は43分12秒、365日間では8時間45分36秒です。ただし「30日間」「時間ベース」「何を停止とするか」という前提が変わると、同じ99.9％でも意味が変わります。
運営担当者が実績を示す際は、計算期間・正常判定・実停止時間・未計測区間を併記し、監視チェックの成功率と実時間ベースの稼働率を混同しないことが大切です。数字を単なる成績表ではなく、障害を減らし復旧を速くするための判断材料として活用してください。
サイトの状態や監視結果を整理する入口として、エンリンクは最大5サイトまで無料で登録できます。サイトの用途と必要な監視頻度に応じて、無理のない運用から始めましょう。
参考にした一次資料：Google SRE Book「Availability Table」、Google Cloud公式「可用性とエラー予算」、AWS Well-Architected「可用性」、Google SRE Workbook「Implementing SLOs」（参照日：2026年10月23日）。
