障害履歴と、その「公開状況」

最終更新: 2026-08-04

「障害が少ない会社はどこか」という問いに、いま正直に答えられるサイトは存在しません。履歴を機械可読で公開しているのが7社中2社しかないからです。このページは比較表ではなく、公開状況の記録と、取得できた範囲の障害ログです。

当サイトは各VPS事業者のアフィリエイトプログラムに参加しており、リンク経由でのお申し込みにより報酬を受け取る場合があります。ただし掲載順位・評価・実測データは編集方針と計測結果のみに基づいており、報酬額による優遇は一切行いません。日本リージョンが無い事業者や、報酬が発生しない事業者も同じ基準で掲載しています。

このページには2つの役割があります。ひとつは各社が障害履歴をどう公開しているかの記録。もうひとつは、取得できた会社に限った障害ログの蓄積です。

先に断っておくと、ここに「障害が少ない会社ランキング」はありません。作れないからです。

なぜ件数の比較を載せないのか

障害履歴を機械可読な形式(Statuspage API)で公開しているのは、当サイトが扱う7社のうち DigitalOcean と Linode の2社だけです。

この状態で件数を並べると、奇妙なことが起きます。Linodeは全リージョンの小さな経路異常まで律儀に記録するため件数が多くなり、ステータスページを持たない会社は0件に見える。つまり誠実に公開している会社ほど不安定に見える逆転が起きます。これは比較として成立していないので、当サイトは件数の横並び比較を載せません。

代わりに載せるのは、次の2つです。

各社の公開状況

サービス障害履歴の公開状況備考
Vultr取得できずstatus.vultr.com がクローラからのアクセスを403で拒否する
Contabo取得できず公開ステータスページが見当たらない
Linode (Akamai)機械可読で公開Statuspage API。当サイトで 2026-03-09 以降を蓄積中(63件)
Hetzner取得できずstatus.hetzner.com はStatuspage形式ではなくAPIが無い
DigitalOcean機械可読で公開Statuspage API。当サイトで 2026-03-17 以降を蓄積中(62件)
RackNerd取得できずstatus.racknerd.com は存在するが Statuspage の API(/api/v2/summary.json)が404。機械可読な履歴を公開していない(2026-08-22 確認)
Oracle Cloud取得できずocistatus.oraclecloud.com は存在するが Statuspage 形式ではなく、/api/v2/summary.json は404(2026-08-22 確認)

確認日: 2026-09-27。「取得できず」は障害が無いという意味ではなく、当サイトが機械的に履歴を取得できないという意味です。

「機械可読で公開」している会社は、障害の発生・経過・復旧を第三者が検証できる形で残しているということです。これ自体がひとつの評価軸だと当サイトは考えています。

取得できた会社の障害ログ

以下は会社ごとに独立した記録です。会社間で件数を比べないでください(記録の粒度が違うため)。見るべきは、影響度「大」以上の頻度と、復旧までの時間です。

DigitalOcean

DigitalOcean: 2026-03-17 〜 2026-09-27 に 62件(重大 2件 / 大 7件 / 小 41件 / 影響なし 12件)。うち日本リージョンのコンポーネントを含むもの 0件。

発生日内容影響度復旧まで
2026-09-16 Support Portal Service Disruption 小 11.4時間
2026-09-09 Power Degradation impacting GPU Performance in ATL1 小 1.6時間
2026-08-24 Cloud Control Panel and API 重大 25.8時間
2026-08-23 Managed Databases Creation 小 9.4時間
2026-08-21 Container Registry and Spaces Accessibility 小 1.9時間
2026-08-19 Major Service Interruption in MKC1 重大 8.4時間
2026-08-08 Account Registration, Droplets, and Related Services 小 6.1時間
2026-08-06 Functions on App Platform 小 2.1時間
2026-08-04 Spaces Cold Storage Billing 小 5.5時間
2026-08-03 Cloud Control Panel Access 小 4.0時間
2026-07-29 Response Degradation Impacting Kimi-K3 小 12.3時間
2026-07-27 Agent Platform Requests Returning HTTP 500 Errors 大 20.9時間

「影響なし」区分を除いた直近12件を表示(日付はUTC)。影響度は各社ステータスページの自己申告です。

Linode(Akamai)

Linode (Akamai): 2026-03-09 〜 2026-09-27 に 63件(重大 2件 / 大 3件 / 小 28件 / 影響なし 29件)。うち日本リージョンのコンポーネントを含むもの 15件。

発生日内容影響度復旧まで
2026-09-25 Service Issue - Cloud Manager and API 小 1.2時間
2026-09-21 Emerging Service Issue - Cloud Manager and API 日本 小 34.2時間
2026-09-07 Service Issue - Cloud Manager and API 小 2.9時間
2026-08-14 Connectivity Issue - IT-MIL (Milan) data center 小 1.3時間
2026-08-13 Service Issue - Linode Kubernetes Engine Enterprise (LKE-E)- IAD2 (Washington) 小 2.2時間
2026-08-13 Service Issue - Linode Kubernetes Engine (IAD2) 小 1.6時間
2026-07-20 Connectivity Issue - Linodes in Milan, Italy 小 2.3時間
2026-07-18 Service Issue - Object Storage 小 1.0時間
2026-07-14 Service Issue - Linode API/CLI 小 7.1時間
2026-06-30 Service Issue - Block Storage - Singapore Expansion, SP (sg-sin-2) 小 4.5時間
2026-06-26 Service Issue - ACLP Metrics 小 282.9時間
2026-06-16 Service Issue: Longview 小 4.3時間

「影響なし」区分を除いた直近12件を表示(日付はUTC)。影響度は各社ステータスページの自己申告です。

この記録の限界

  • 蓄積は2026年8月開始です。各社APIは直近50件しか返さないため、遡れたのは2026年3月頃まで。それ以前の履歴は存在しません。当サイトが毎日収集を続けることで、蓄積期間は今後伸びていきます
  • 影響度(重大/大/小)は各社の自己申告です。同じ規模の障害でも会社によって申告が違う可能性があります
  • 取得できない5社についても、取得手段が見つかり次第この記録に加えます

よくある質問

障害件数が多い会社は避けるべきですか

件数だけでは判断できません。障害履歴を詳細に公開している会社ほど件数が多く見えるためです。たとえば全リージョンの小さな経路異常まで記録する会社と、ステータスページ自体を持たない会社を件数で比べると、透明性の高い会社のほうが不安定に見えるという逆転が起きます。

履歴が取得できない会社は障害が多いのですか

分かりません。取得できないのは「当サイトが機械的に履歴を読めない」という意味であり、障害の多さとは別の話です。ただし、障害履歴を検証可能な形で公開しているかどうか自体は、事業者の透明性を測る材料になります。

なぜ2026年3月以前の履歴がないのですか

各社のステータスページAPIが直近50件しか返さないためです。当サイトは2026年8月から毎日収集を続けて履歴を継ぎ足しており、蓄積期間は今後伸びていきます。収集開始より前の期間は後から取得できません。