Garantierte Betriebszeit

Bei Kinsta bieten wir zwar kein Hochverfügbarkeits-Hosting (HA), aber eine durch Service Level Agreements (SLA) abgesicherte Betriebszeitgarantie. Bei Kinsta läuft jede Website auf unserer Plattform in einem einzigen Linux-Container, und die Website-Datenbank wird als Dienst innerhalb des Website-Containers ausgeführt, und zwar auf leistungsstarken Servern der Enterprise-Klasse. Wir betreiben nicht mehrere lastverteilte Instanzen jeder Website-Infrastruktur.

Weitere Informationen zu unserer Infrastruktur und Architektur findest du hier:

• Infrastruktur für Anwendungs- und Datenbankhosting
• Hosting-Infrastruktur für statische Websites
• WordPress-Hosting-Infrastruktur

Dank der Flexibilität einer Container-basierten Infrastruktur, des proaktiven Lastmanagements durch unser Engineering-Team und der Nutzung führender Cloud-Plattformen können wir eine SLA-gestützte Betriebszeitgarantie von bis zu 99,9 % bieten. Für kundenspezifische Pläne können wir eine erweiterte Betriebszeitgarantie von bis zu 99,99 % anbieten. Wenn du mehr darüber erfahren möchtest, wende dich bitte an unser Vertriebsteam.

Wartungszeitraum

Kinsta wartet jeden Tag von Montag bis Sonntag zwischen 2 Uhr und 5 Uhr morgens Ortszeit, basierend auf der Zeitzone des Rechenzentrums, in dem die jeweilige Anwendung gehostet wird. Wir senden keine Überwachungsbenachrichtigungen, wenn während dieser Zeit Wartungsarbeiten durchgeführt werden. Weitere Informationen findest du in der Service Level Vereinbarung von Kinsta.

Umstände, die die Überwachung der Betriebszeit blockieren

Um sicherzustellen, dass wir unsere Betriebszeitgarantie einhalten, überwachen wir jede Website auf unserer Plattform auf ihre Betriebszeit. Wenn einer unserer Betriebszeitmonitore ausfällt, reagieren unsere Techniker sofort und arbeiten daran, den Service für die Website wiederherzustellen. Es gibt jedoch einige Szenarien, in denen unsere Fähigkeit, die Betriebszeit zu überwachen, eingeschränkt sein kann:

• Wenn du die Basisauthentifizierung aktiviert hast, wird bei allen nicht autorisierten Anfragen ein 401-Fehler ausgegeben.
• Der „Ich werde angegriffen“-Modus von Cloudflare hat eine 5-sekündige Wartezeit, um DDoS-Angriffe zu verhindern. Dies gilt nicht für HEAD-Anfragen, denn diese werden mit einem 503-Fehler beantwortet.
• Reverse-Proxy-Websites, bei denen die primäre Domain nicht auf die Ziel-URL umleitet.
• Bestimmte Fälle von benutzerdefiniertem Caching können Probleme verursachen. Zum Beispiel, wenn du den Query String HEAD Request von Kinsta zwischenspeicherst. Auch Proxy-Dienste wie Sucuri und Cloudflare können je nach Konfiguration manchmal Probleme mit dem Caching verursachen.
• Bot-Blockierdienst: Unser Uptime-Monitor verwendet kinsta-bot als User-Agent. Wenn du ihn also mit einem Plugin oder Dienst blockierst (User-Agent Deny), kann dies dazu führen, dass unsere Betriebszeit-Überwachung fehlschlägt (dies führt normalerweise zu einem 406-Antwortcode).
• Wenn du die IP-Adresse(n) oder das Herkunftsland unseres Betriebszeit-Monitors blockierst (Geo-Block), hat das Auswirkungen auf unsere Überwachung. Wenn du diese Funktionen auf den Servern von Kinsta konfigurierst, ist das kein Problem, da wir Ausnahmen hinzufügen.
• Wenn die primäre Domain nicht zu der Installation aufgelöst werden kann, zu der sie hinzugefügt wurde, oder wenn sie auf eine andere Domain umgeleitet wird (die in der Domainliste der gleichen Website aufgeführt ist).
• Wenn sich eine Website im Wartungsmodus befindet, kann sie eine 503-Antwort zurückgeben.