Kinstaは高可用性（HA）ホスティングを提供しませんが、SLAによるアップタイム保証は提供しています。Kinstaのプラットフォーム上の各サイトは単一のLinuxコンテナで実行され、サイトデータベースはサイトコンテナ内のサービスとして実行されます。ロードバランス等の目的で、各サイトの複数インスタンスを実行することはありません。詳細については記事「Kinstaのアーキテクチャ」をご覧ください。

コンテナベースのインフラストラクチャ、エンジニアリングチームによるプロアクティブな負荷管理、クラス最高のクラウドプロバイダーGoogle Cloud Platformの柔軟性により、KinstaはSLAによる99.9%のアップタイム保証を提供します。

アップタイムモニターが妨害されるシナリオ

確実にアップタイム保証を満たすため、Kinstaはプラットフォーム上のすべてのサイトのアップタイムを監視しています。アップタイムモニターで障害が発生した場合、当社のエンジニアが直ちに対応し、サイトのサービス復旧に努めます。しかし、アップタイムモニターの機能が制限されるシナリオがいくつかあります。

  • 基本認証が有効な場合、すべての未承認リクエストに対して401エラーを返します。
  • Cloudflareの「I’m under attack」モードでは、DDoS攻撃を避けるために5秒の待機時間があります。これはHEADリクエストには適用されず、503エラーを返します。
  • リバースプロキシサイトで、プライマリドメインがターゲットURLにリダイレクトしていない場合。
  • カスタムキャッシュの特定のインスタンス、例えば、Kinstaのクエリ文字列のHEADリクエストをキャッシュすると、問題が発生する場合があります。SucuriやCloudflareなどのプロキシサービスも、設定によってはキャッシュで同様の問題が発生します。
  • ボットブロックサービス。Kinstaのアップタイムモニターはユーザーエージェントとしてkinsta-botを使用します。プラグインやユーザーエージェント拒否サービスでボットをブロックすると、アップタイムモニターが失敗し、通常は、406レスポンスコードを返します。
  • アップタイムモニタのIPアドレス、または発信国（Geo-block）のいずれかをブロックすると、監視に影響します。Kinstaのサーバーでこの機能を構成する場合は例外が追加されるため、問題になりません。
  • プライマリドメインが、追加されたインストールに解決しないか、または同じサイトのドメインリストに含まれる別のドメインにリダイレクトされている場合。
  • サイトのメンテナンスモード時。503レスポンスを返す場合があります。