SpeedCurve（スピードカーブ）は、日本時間2026年5月8日（金）午前5:00に行われたデプロイメントにより、同社のRUM（リアルユーザーモニタリング）JavaScriptエラー追跡機能が5日間、5月13日（水）午前5:00まで停止し、詳細なエラー情報が失われたものの、集計されたエラー数は保持されたと報告した。
このインシデントは、RUMスクリプトlux.jsと、サービスの2部構成のエラー収集システムに影響を与えた。SpeedCurveは、JavaScriptエラーの総数カウントは引き続き正常に機能していたものの、エラーメッセージ、ファイル名、行、列などのサンプリングされたエラーペイロードが欠落したと説明した。特定のエラーメッセージでダッシュボードをフィルタリングする際に例外が発生し、詳細データが欠落していることが影響している可能性があるとのことだ。
5月4日（月）に行われた段階的なアップデートにより、ステージング環境に新しいビーコンエンドポイントとlux.js v4.5が導入された。SpeedCurveによると、5月8日（金）午前5:00ごろに新しいlux.js v4.5が本番環境にデプロイされたが、それに伴うエンドポイントはデプロイされていなかったため、エラービーコンが404応答を受け取り、その詳細が破棄されるという問題が発生した。5月8日（金）19:00までに、RUMトラフィックのほとんどが新しいlux.jsバージョンを使っていると報告された。
自動監視システムは当初、JavaScriptエラーの発生件数がインジェストパイプラインで急激にゼロに低下したことを検知したが、社内テストアカウントでのスポットチェックの結果、監視システムの問題であることが判明した。SpeedCurveは、Fastlyがプッシュした、RUMビーコンのエラー数を可視化することを目的とした指標が、障害発生中に増加しなかったことを指摘した。その理由は不明のままで、エラー率が正常であるように見え、本番環境データの不足が見過ごされた。
5月11日（月）19:00に顧客からJavaScriptエラーの詳細が欠落しているという報告があり、SpeedCurve社はこれを認識した。同社によると、この報告は5月13日（水）午前4:00までエンジニアリングチームに転送されず、35時間の遅延があったとのことだ。5月13日（水）午前4:00、エンジニアリングチームはエンドポイントの欠落が根本原因であることを特定し、数分以内に修正をデプロイした。修正は同日午前4:20に完了した。
SpeedCurveは、今回の障害はリリースプロセスと監視体制の不備に加え、人的ミスが重なったことが原因だと説明した。影響を受けたシステムのリリースワークフローは完全に手動であり、監視体制が限定的でステージング環境のみでの抜き打ちチェックしか行っていなかったため、迅速な検出ができなかったという。同社は、顧客からの報告をエスカレーションするまでに35時間もかかったことが、障害の長期化を招いたと指摘した。
今後のリスクを軽減するための計画変更点として、監視範囲の拡大、ステージングデータと本番データの両方を検証するスポットチェックの改善、影響を受けるシステムをサポートするためのエンジニアの追加配置などが挙げられた。SpeedCurveは、support@speedcurve.comに問題を報告してくれた顧客に感謝の意を表し、インシデント発生時に寄せられたフィードバックと忍耐に感謝の意を表明した。
出典：SpeedCurve
この製品の詳細については、SpeedCurve製品ページをご覧ください。
