Betrieb

Was kaputt ist, und seit wann

Die Statusseite wird von denselben Probes gespeist, die auch den Bereitschaftsingenieur wecken. Zwischen einem fehlgeschlagenen Check und einem roten Panel gibt es keinen redaktionellen Schritt. Das ist beabsichtigt und gelegentlich peinlich.

Flotte
12-Monats-Uptime99.993%
SLA-Ziel99.99%
Standorte34
Offene Störungen0
Alle Systeme betriebsbereit
Europe
North America
MIA-01 Miami100.000%
Latin America
Asia-Pacific
Middle East & Africa

90 Tage · Latenzwerte sind gemessene Mediane von unseren eigenen Sonden, nicht Verkaufsbroschüren. Sie bewegen sich; die Seite aktualisiert sich, wenn sie es tun.

01

Was die Seite zeigt

Probes laufen alle 30 Sekunden von außerhalb unseres eigenen Netzwerks. Der Verlauf bleibt 90 Tage erhalten.

01

Pro Standort, nicht pro Flotte

Alle 34 Standorte sind einzeln aufgeführt. Ein Problem in einer Stadt färbt nicht auf die anderen ab, denn eine aggregierte Verfügbarkeitskennzahl verdeckt genau den Ausfall, wegen dem Sie die Seite aufgerufen haben.

02

Sechs Komponenten pro Standort

Netzwerk, Hypervisor, Storage, Provisioning, Panel und API, jeweils unabhängig geprüft. Eine sich stauende Provisioning-Warteschlange behauptet also nicht, dass Ihre laufenden Instanzen down sind.

03

Von außen gemessen

Probes sitzen in Netzwerken, die wir nicht betreiben, in mehreren Regionen, und ein Check muss von mehr als einem Standort aus fehlschlagen, bevor sich etwas verfärbt. Ein Netzwerk von innen zu überwachen misst sehr wenig.

04

Dieselbe Uptime-Kennzahl wie im SLA

99,993 % über die letzten 12 rollierenden Monate, berechnet aus diesen Probes und nicht nach einer freundlicheren Definition. Ausfallzeit zählt ab dem ersten fehlgeschlagenen Check, nicht ab dem Moment, in dem jemand ihn bestätigt hat.

05

Nachbereitung nach Incidents

Alles, was als P1 oder P2 eingestuft wird, erhält innerhalb von 5 Arbeitstagen einen schriftlichen Nachbericht: Was kaputt war, was getan wurde, was danach geändert wurde. Sie sind absichtlich trocken und werden niemals stillschweigend gelöscht.

02

Wie Incidents eingestuft werden

Vier Stufen, vom Bereitschaftsingenieur innerhalb von Minuten vergeben und ohne Zögern nach oben korrigiert, wenn sich das Bild ändert. Danach wird nichts herabgestuft, damit ein Bericht besser aussieht.

StufeBedeutungErstes UpdateDanach
P1Kundeninstanzen an einem Standort down oder nicht erreichbar, oder ein Fehler, der mehr als einen Standort betrifft.Innerhalb von 15 MinutenAlle 30 Minuten bis zur Lösung
P2Schwere Beeinträchtigung. Paketverlust, Speicherlatenz oder eine Komponente down, während Instanzen weiterlaufen.Innerhalb von 30 MinutenStündlich
P3Fehler auf der Control Plane. Provisioning, Panel, API oder Abrechnung nicht verfügbar, während laufende Instanzen nicht betroffen sind.Innerhalb von 2 StundenZweimal täglich
P4Kosmetisch oder einzelne Instanz. Ein festhängendes Warteschlangenelement, ein falscher Graph, ein einzelner Knoten beeinträchtigt, wobei ein Hot Spare bereits trägt.Nächster ArbeitstagBei Lösung

Eine einzelne fehlgeschlagene Kundeninstanz ist auf dieser Seite eine P4 und im Panel ein Ticket mit einer Median-Antwortzeit von 11 Minuten. Die Stufe beschreibt den Blast Radius und nicht, wie sehr es Sie betrifft.

03

Wartung

Geplante Wartungen werden mindestens 7 Tage im Voraus angekündigt, per E-Mail an die betroffenen Konten und auf der Statusseite. Reseller erhalten 14 Tage. Jede Ankündigung nennt den Standort, das Zeitfenster, die erwarteten Auswirkungen und ob ein Neustart ansteht.

Fenster laufen von 01:00 bis 05:00 Uhr Ortszeit am Standort, was die einzig vernünftige Wahl ist, wenn die Flotte über 29 Länder verteilt ist und immer jemand wach ist. Die meiste Arbeit ist innerhalb der ersten Stunde erledigt.

Wo eine Workload live migriert werden kann, wird sie das, und der sichtbare Effekt sind ein paar Sekunden zusätzliche Latenz statt eines Neustarts. Firmware-, Kernel- und Hypervisor-Arbeiten lassen sich so nicht erledigen, und die Ankündigung sagt das deutlich, anstatt einen Neustart hinter dem Wort „kurz“ zu verstecken.

01

Notfallwartung

Angekündigt, sobald die Entscheidung gefallen ist, manchmal mit weniger als einer Stunde Vorlauf. Reserviert für Sicherheitsfixes bei aktiver Ausnutzung oder Hardware, die ohnehin ausfällt.

02

Aufschübe

Eine pro Instanz und Quartal, per Ticket, bis zu 14 Tage. Danach muss der Knoten erledigt werden, und wir helfen Ihnen, sich auf den Termin einzustellen, anstatt ihn erneut zu verschieben.

03

Was in einem Wartungsfenster nie passiert

Preisänderungen, Richtlinienänderungen und alles, was Ihre Daten betrifft. Wartung umfasst Hardware und Software, die wir betreiben, niemals den Inhalt Ihrer Festplatten.

04

Darüber informiert werden

Vier Wege zu abonnieren. Keiner davon erfordert ein Konto, und keiner wird jemals verwendet, um Ihnen etwas anderes als Vorfälle zu senden.

01

Atom-Feed

Ein Feed für alles oder einer pro Standort. Es ist die Option, die weiter funktioniert, wenn E-Mail nicht funktioniert, was während eines Netzwerkvorfalls genau die Situation ist, in der Sie sich befinden.

02

E-Mail pro Standort

Abonnieren Sie eine Adresse für die Städte, die Sie nutzen. Kunden werden automatisch für ihre eigenen Standorte abonniert und können es abschalten, auch wenn wir es lieber nicht sähen.

03

Webhooks

Ein signiertes POST bei jeder Zustandsänderung, für alle, die Vorfälle in ihre eigene Tooling-Route einspeisen. Gleiche Payload-Form wie die API, 24 Stunden lang mit Backoff wiederholt.

04

Die Status-API

Ein öffentlicher Read-only-Endpunkt, der aktuellen Zustand und offene Vorfälle als JSON zurückgibt. Kein Token erforderlich, höflich limitiert und seit 2024 unverändert.

Das ist die gesamte Verwendung der Adresse. Es gibt keinen Newsletter, keine Produktankündigungs-Mailings und keine Marketingliste, in die Sie durch ein Status-Abonnement stillschweigend aufgenommen werden.

05

Status-Fragen

Weil sie Standorte und Komponenten verfolgt, nicht einzelne Instanzen. Ein Knoten oder eine Instanz ist ein Ticket, kein öffentlicher Vorfall, und das Ticket ist der bei weitem schnellere Weg zu einer Lösung.

Bewusst nicht auf der Infrastruktur, die sie überwacht. Sie wird von einem separaten Standort mit separatem Transit ausgeliefert, sodass ein Netzwerkfehler nicht die Seite beschädigen kann, die diesen Fehler beschreibt.

Angekündigte Fenster werden nicht auf die SLA-Zahl angerechnet. Alles andere schon, einschließlich der Ausfälle, die unsere Schuld waren, und derer, die jemand anderen Schuld waren.

Neunzig Tage auf der Seite selbst und unbegrenzt für P1- und P2-Berichte. Alte Vorfälle werden nicht entfernt, sobald sie unangenehm werden.

Jede Standortseite führt Umlaufzeiten von den vier Referenz-Hubs aus, kontinuierlich aktualisiert. Die auf den Standortseiten angegebenen Zahlen sind Mediane genau dieser Daten.

Bereit, wenn Sie es sind

Abonnieren, bevor Sie es brauchen

Der Feed und die standortbezogene E-Mail benötigen eine Adresse und etwa zehn Sekunden. Dies während eines Vorfalls zu tun ist möglich und erheblich unangenehmer.