#ステータスシステム

Disbandのステータスページは自己ホストされています。 3 社間のステータス サービスに依存しないため、メイン Web ホストである API または静的アセット配信に問題が発生した場合でも、正確な報告を行うことができます。

• 公開ページ：disband.dev/status
• RSSフィード：disband.dev/status/feed.xml
• オーナー管理者：disband.dev/status/admin

#公開ページに表示されるもの

このページでは、サービス別モニターがグループ化されています。各モニターには、次の情報が表示されます。

• 最新のチェックからの現在の状態。
• そのチェックのHTTPステータスと応答時間。
• 90日間の稼働時間バー、1日1つのセグメント。
• 最後にチェックが実行されたとき。

モニターの下には、インシデント、スケジュールされたメンテナンス、およびお知らせがあります。それぞれが、完全な更新タイムラインを含む詳細ページを開きます。フィードは、RSS 2.0として最新の25件のインシデント、メンテナンスウィンドウ、および公開されたお知らせを配信します。

#チェック

status-probeと呼ばれるSupabase Edge関数がpg_cronの下で毎分実行されます。 すべての有効なモニターを並行してプローブし、チェックごとに1行を記録します。

各モニターには次のものが含まれます。

モニターは、ステータスコードが一致し、オプションのキーワードが存在する場合にのみ正常です。リダイレクトは従います。タイムアウト、ネットワークエラー、ステータスが正しくない、またはキーワードが欠落している場合は、理由とともにチェックに失敗したとして記録されます。

プローブはウェブアプリとは独立して実行されます。ウェブホストの障害があっても、チェックの記録は停止しません。

#履歴と稼働時間

すべてのチェックはstatus_checksに保存されます。データベーストリガーは各チェックをstatus_dailyに折りたたみます。したがって、90日間のバーは、何百万人もの行をアグリゲートするのではなく、安価な読み取りです。

• 未加工のチェックは90日間保管されます。
• 毎日のロールアップは180日間保持されます。
• 公開ページには最新の90日間が表示されます。
• 各日のセグメントは、その日の成功したチェックの割合です。

チェックが行われていない日（ギャップ）は、ダウンタイムではなく、データなしとして表示されます。

#自動発生事故

プローブは、モニターが3回連続でチェックに失敗した場合、自動的にインシデントを開きます。インシデントは、そのモニターに関連付けられた重大なインシデントであり、最後のエラーを含む自動更新で調査を開始します。

次のチェックが成功すると、インシデントは解決済みに移動し、障害が発生した時間が概算的に記録されます。インシデントは、完全な履歴とともにページとフィードに残ります。

サービスがフラップしている場合でも、連続して3回失敗していない場合は、自動インシデントは開かれません。 所有者は、インシデントが開いている間、まだ手動更新を追加できます。

#手動の事件、メンテナンス、およびお知らせ

オーナーは、次の3種類のエントリーを投稿できます。

イベントは、1つ、複数、またはすべてのモニターに影響を与える可能性があります。その影響は、none、minor、major、またはcriticalのいずれかになります。

更新ステータスは次のとおりです。

• investigating
• identified
• monitoring
• resolved
• scheduled
• in_progress
• completed
• published

各更新により、インシデントタイムラインにタイムスタンプ付きのエントリが追加され、インシデントの現在のステータスが設定されます。更新をresolvedまたはcompletedとマークすると、解決時間も設定されます。別のステータスで後続の更新を投稿すると、インシデントが再び開きます。

#全体的な状況

バナーは次の順番で決定されます。

1. アクティブなメンテナンスウィンドウに「メンテナンス中」と表示されている場合、または 開始前にスケジュールされたメンテナンス。
2. アクティブなメジャーまたはクリティカルインシデントには「メジャー障害」と表示されます。
3. アクティブな軽度のインシデントには「部分的に劣化」と表示されます。
4. モニターが故障している場合は、すべてのモニターで「部分的に劣化」または「大きな障害」と表示されます。 公共モニターが故障しています。
5. 失敗がなく、少なくとも 1 つの結果がある場合、「すべてのシステムが正常に動作しています」と表示されます。
6. 最初のチェックが到着する前に、「最初のチェックを待っています」と表示されます。

解決済みの事件はバナーに影響しません。

#プライバシー

公開読み取りパスは、直接テーブルへのアクセスではなく、データベース機能です。モニタ名、グループ、ステータス、レイテンシ、稼働時間、およびインシデントを返します。意図的に省略されています。

• URLsを監視する。
• リクエストヘッダー；
• プローブエラーテキスト;
• 内部チェックID;
• 事件更新の背後にある人物。

基本テーブルには、パブリックポリシーなしで行レベルのセキュリティが有効になっています。サービスロールとプローブ機能のみが直接読み込むことができます。

#管理

/status/adminは、サインインしたプラットフォーム所有者にのみ制限されています。スペースロールではなく、他のメンバーに割り当てることはできません。認証されていないリクエストには401が返されます。他のサインインしたアカウントには403が返されます。

管理画面は次のことができます。

• モニターを作成、編集、有効化、無効化、公開、または削除する。
• 各モニターのURL、ヘッダー、および最終結果を確認します。
• 事件後、メンテナンスウィンドウ、および発表を投稿する。
• タイムラインの更新を追加し、インシデントの影響や影響を受けるサービスに変更する。
• モニターとその履歴を削除します。

#管理者API

この画面では、これらのオーナー専用ルートを使用します。

彼らはオーナーのSupabaseアクセストークンをAuthorization: Bearer <token>として受け付けます。それらは、公開のAPIではなく、管理画面の実装詳細です。形状は変更される場合があります。

#運用ノート

• プローブは、Supabase Vaultに保存されている秘密で認証されます。 status_probe_key。秘密はデータベース内で比較され、ありません。 関数に戻りました。
• pg_cronジョブはstatus-probeと名付けられています。それはVaultから秘密を読み取ります すべての実行で、秘密を回転させるにはジョブの編集は必要ありません。
• エッジ機能は、JWT検証をオフに配置されています。なぜなら、それは 代わりにVaultの秘密で認証します。
• プローブ自体が実行を停止した場合、ページは古いと表示されます。 最後に確認された回数。これは、クロンジョブとEdgeを検査するためのシグナルです 機能ログ。

#関連した

• Webhook — 障害通知をチャンネルに送信します。
• 埋め込み — それらの通知をフォーマットします。