システムステータス

計測していない数字は、載せない。

多くのステータスページは、初日から9の並んだ数字を掲げます。ここにはありません。それを計測できるほど長くは、まだ走っていないからです。

このページは、まだ稼働していません。 外形監視はまだ導入していません。そのため、表示できる稼働率も、コンポーネントの状態も、インシデント履歴もありません。計測していない数字を掲載することは、数字を作ることと同じです。プローブが稼働し、3か月分のデータが揃った時点で、このページは実測値の表示を始めます。

なぜ空なのか

計測していない99.99%は、ただの飾りです。

稼働率の数字は、書くだけなら簡単で、検証は困難です。ここに数字を置いても、読み手には実測値と区別がつきません。だからこそ、置かないことにしています。

いままさに評価中で可用性の確約が必要なら、それはマーケティングページではなく、契約に書かれるべきものです。Enterprise契約には明示的なSLAが含まれます。 お問い合わせください 。現行の契約条件をお送りします。

コンポーネントの死活確認

REST API
12 ms(中央値)
正常
Webアプリケーション
13 ms(中央値)
低下
認証
10 ms(中央値)
正常
配信パイプライン
12 ms(中央値)
正常

現時点の死活確認のみ。稼働率は90日分のサンプルが貯まってから公開します — 1,000/259,200 件収集(0%)。

今後ここに表示されるもの 提供予定

コンポーネント別稼働率
API、アプリケーション、配信、認証
進行中のインシデント
検知から5分以内に掲載
計画メンテナンス
最低72時間前に告知
インシデント履歴
文書のポストモーテム付き

確定済みの計測方法 提供予定

どう計測するのか。

数字が出る前に計測方法を確定しておけば、後から自分たちに都合のよい定義を選ぶことができなくなります。

自社ネットワークの外から

プローブは4つのリージョンから30秒ごとに、実際のリクエスト経路に対して実行します。製品が壊れていてもOKを返すだけの、ヘルスエンドポイントは見ません。

「遅い」は停止に数える

5秒を超える応答は、最終的に200が返っても障害として数えます。待っている側にとって、「劣化」と「停止」は同じものだからです。

コンポーネント別

APIが正常でも、配信だけが劣化していることはあり得ます。システム全体を1つの数字で報告すると、本当に知りたい障害が隠れてしまいます。

ポストモーテムを公開

30分を超えた障害には、5営業日以内に文書のポストモーテムを公開します。当社の判断ミスも含めて。


いま何かが壊れていたら

このページが稼働を始めるまでは、直接こちらへお知らせください: [email protected]。ワークスペース名とおおよその発生時刻を添えていただければ、ほとんどの場合、再現をお願いすることなくログから特定できます。

Enterpriseのお客様には、直通のエスカレーション窓口と、営業時間内の担当者を明示して提供します。これは未構築のツールに依存しない、今日の時点で約束できるコミットメントです。

エージェントが何で動いているのか。推測は、もう終わり。

ワークスペースをひとつ接続するだけで、チームで動いているスキル・ルール・メモリの全体が見えます。所要はおよそ10分です。

無料で始める 相談する

クレジットカードは不要です。いまお使いのツールのままで動きます。