Dokumentierte Fallstudie · Belegstand: 30. Oktober 2026
Am 23. Oktober liefen zwei virtuelle private Server von OVHcloud in Zürich und waren auf automatische monatliche Verlängerung eingestellt. Am 30. Oktober waren beide weiterhin im Kundenkonto aufgeführt, ihr Status hatte sich jedoch auf abgelaufen und gestoppt geändert. Die automatische Verlängerung blieb aktiviert; als Ablaufdatum war weiterhin der 23. Oktober vermerkt.[1]
Zwischen diesen Beobachtungen liegt ein Problem für die betriebliche Planung: Wie soll ein Kunde handeln, wenn das Verwaltungsportal eine automatische Verlängerung anzeigt, Erinnerungen eine manuelle Verlängerung verlangen und der Support auf ein Bestätigungsbanner verweist, das VPS-Dienste ausdrücklich ausnimmt? Die Unterlagen dokumentieren diesen Widerspruch. Sie belegen nicht, warum die Verlängerung ausblieb oder ob ein Zahlungsversuch erfolgte.[7]
Diese Fallstudie stützt sich auf Unterlagen aus der technischen Beratungstätigkeit des Herausgebers. Kunden- und Dienstkennungen werden nicht veröffentlicht; die Entscheidungen des Beraters werden ebenso betrachtet wie die Antwort des Anbieters. Die Konsequenzen betreffen jedes Unternehmen, das mit gehosteter Infrastruktur plant. Die Belege beschreiben dieses Kundenkonto, nicht die Leistung von OVHcloud insgesamt.
Planen Sie eine Überprüfung Ihres Hostings? Besprechen Sie Serververfügbarkeit, Verlängerungskontrollen und Wiederherstellungsplanung mit unserem Engineering-Team.
Ein früherer Server war bereits verschwunden
Beim früheren Zürcher VPS dieses Kontos handelte es sich um einen eigenständigen Dienst. Spätestens am 2. Oktober fehlte er in der Serverliste des Kontos. Eine zeitgenössische Aufzeichnung hielt die Bestätigung des Nutzers fest, dass er gelöscht worden sei. Spätere Anfragen über die Programmierschnittstelle von OVHcloud, kurz API, lieferten die Antwort, dass der Dienst nicht existiere.[2]
Seine Verlängerungshistorie ist wesentlich. Eine gespeicherte API-Antwort vom 10. September zeigte manuelle Verlängerung und den 20. September als Ablaufdatum. Eine am 17. September weitergeleitete Erinnerung führte diesen Server und seine Optionen zur manuellen Verlängerung auf. Auf die Frage des Kunden, ob eine weitere Freigabe erforderlich sei, antwortete der Berater, die Einstellungen sollten bereits passen, und sagte eine erneute Prüfung zu.[3]
OVHcloud erklärte später, die automatische Verlängerung sei für diesen früheren Dienst nicht vollständig eingerichtet gewesen. Die September-Einstellung stützt den Teil dieser Erklärung, der sich auf die manuelle Verlängerung bezieht. Sie belegt weder den genauen Löschzeitpunkt noch die auslösende Person oder den automatisierten Vorgang noch einen dauerhaften Datenverlust. Die geprüften Unterlagen enthalten kein Löschprotokoll, das diese Fragen klärt.[2][7]
Ein separater Supportfall im September betraf QXL-Fehler der virtuellen Grafik und eine später dokumentierte Verzögerung beim Neustart. Laut ursprünglicher Meldung waren keine Auswirkungen auf die Anwendungsleistung beobachtet worden. OVHcloud verlangte Diagnosetests. Die Unterlagen enthalten eine ausführliche Kundenantwort, belegen jedoch nicht die Durchführung sämtlicher angeforderter Tests. Diese Vorgeschichte weist keine Ursache für das spätere Verschwinden oder Ablaufen der Dienste nach.[4]
Die späteren Server hatten eine andere Verlängerungshistorie
Die beiden späteren Zürcher VPS erschienen in einer frühen Erfassung vom 2. Oktober zunächst mit manueller Verlängerung. Nach einer gemeldeten Einstellungsänderung bestätigte eine weitere Prüfung am selben Tag die automatische monatliche Verlängerung. Weitere Prüfungen am 8., 20. und 23. Oktober dokumentierten dieselbe Konfiguration.[5]
Die API zeigte aktivierte automatische Verlängerung, einen Verlängerungszeitraum von einem Monat, deaktivierte manuelle Zahlung und deaktivierte Löschung bei Ablauf. Am 23. Oktober liefen beide Server mit dem Dienststatus OK. Ein an diesem Tag bereitgestellter Screenshot zeigte sie ebenfalls als aktiv, mit automatischer Verlängerung jeden Monat.[1]
Diese Prüfungen belegen die konfigurierten Einstellungen zuverlässig. Sie zeigen nicht, dass die nächste Rechnung beglichen oder die Laufzeit verlängert worden war. Im Konto waren eine Standardzahlungsmethode und eine frühere Übersicht bezahlter Rechnungen vorhanden. Beides belegte jedoch keine Zahlung für die bevorstehende Verlängerung in Zürich.[6]
Die Anzeige „No commitment“ – keine Vertragsbindung – stand im Verwaltungsportal neben der automatischen Verlängerung. Sie bedeutete nicht, dass diese deaktiviert war. Ebenso belegt eine vom Kunden vergebene Kennzeichnung „LIVE“ weder die ausgeführten Arbeitslasten noch den Ausfall einer öffentlich erreichbaren Website oder Auswirkungen auf den Umsatz.[1]
Der Support antwortete, doch die erforderliche Handlung blieb unklar
Eine am 8. Oktober eröffnete Supportanfrage bat OVHcloud, automatische Verlängerung und Zahlung zu bestätigen, gegebenenfalls erforderliche weitere Schritte zu benennen und das Verschwinden des früheren Servers zu erklären. Eine Kündigung oder Löschung wurde ausdrücklich nicht autorisiert. Die erste sichtbare Antwort eines Supportmitarbeiters in diesem Ticket datiert vom 23. Oktober: ein Abstand von ungefähr 15 Kalendertagen.[7]
Die Antwort enthielt eine Entschuldigung für die Verzögerung. Der frühere Server sei nicht vollständig für automatische Verlängerung konfiguriert gewesen. Bei den anderen VPS sei die automatische Verlängerung eingeleitet worden, müsse aber noch im roten Bereich der Abrechnungsseite bestätigt werden.[7]
Das rote Banner im am 23. Oktober bereitgestellten Screenshot begann jedoch mit dem Hinweis, in deutscher Übersetzung: „Diese Nachricht gilt nicht für Bare-Metal- und VPS-Dienste.“ Der übrige Bannertext bezog sich auf eine noch nicht autorisierte Option zur automatischen Verlängerung.[1] Wer der Supportantwort folgte, wurde damit offenbar auf eine Warnung verwiesen, die das betroffene Produkt ausnahm.
Aus den Unterlagen geht nicht hervor, was diese Bestätigung im Hintergrund geändert hätte. Sie zeigen jedoch, warum die Antwort nicht konkret genug war: Sie brachte die Ausnahme für VPS nicht mit der verlangten Handlung in Einklang und benannte keinen gescheiterten Zahlungsversuch.
Ein zweites Ticket zum Widerspruch zwischen Erinnerungen und Einstellungen wurde am 21. Oktober eröffnet und am 23. Oktober als Duplikat des ersten geschlossen. Das Schließen doppelter Fälle belegt für sich genommen keine mangelhafte Bearbeitung. Hier führte es den Kunden jedoch zur selben Antwort zurück, ohne den Widerspruch aufzulösen. Zum ursprünglichen Ticket folgte später eine automatisierte Abschlussnachricht. Am 30. Oktober widersprach der Kunde der Antwort und verlangte die Wiederherstellung der Dienste.[8][7]
Die Erinnerungen betrafen die Server selbst
Die Verlängerungshinweise umfassten die Server selbst ebenso wie optionale Zusatzleistungen. Die Nachrichten vom 23. und 24. Oktober führten beide Zürcher Basis-VPS sowie deren Snapshot- und Speicheroptionen unter manueller Verlängerung auf. Die Nachricht vom 24. Oktober zeigte weiterhin den 23. Oktober als Ablaufdatum unter einer Überschrift für Dienste, die an diesem Tag ablaufen.[9]
Diese Hinweise waren Warnungen. Es wäre daher unzutreffend zu behaupten, der Kunde habe keine erhalten. Das Problem war ihr Widerspruch zu den gespeicherten Verlängerungseinstellungen. Die Kontounterlagen erklärten dem Kunden nicht eindeutig, welche Information für den nächsten Schritt maßgeblich sein sollte.
Auch die Zusicherung des Beraters gehört zu dieser Entscheidungsgeschichte. Am 20. Oktober bestätigte er die automatischen Einstellungen und erklärte, sie müssten nicht erneut aktiviert werden, während er zugleich auf die unerklärte Erinnerung einging. Eine versandte E-Mail vom 23. Oktober bestätigte erneut, dass die Server liefen und die automatische Verlängerung aktiviert war. Sie bezeichnete die E-Mails als vermutlich irreführend und kündigte eine erneute Prüfung für den 24. Oktober an.[10]
In den geprüften Belegen wurde keine abgeschlossene Nachprüfung vom 24. Oktober gefunden. Das beweist nicht, dass keine Prüfung stattfand. Die Zusicherung beruhte auf verifizierten Einstellungen; eine beglichene Zahlung und eine verlängerte Laufzeit blieben unbestätigt.[10]
Abgelaufen und gestoppt, bei weiterhin aktiver automatischer Verlängerung
Am 30. Oktober zeigten die Screenshots des Kunden beide späteren Dienste als abgelaufen, während die Kennzeichnung für automatische Verlängerung erhalten blieb. Die API erfasste beide VPS als gestoppt, ihren Dienststatus als abgelaufen und weiterhin den 23. Oktober als Ablaufdatum. Sie verzeichnete nach wie vor automatische Verlängerung mit einem Zeitraum von einem Monat.[1]
Hinzu kam ein weiteres Anzeigedetail: Unter „Automatisch“ zeigte das spätere Dashboard keine Verlängerungsfrequenz, während der frühere Screenshot „Jeden Monat“ ausgewiesen hatte. Die Ein-Monats-Einstellung der API blieb bestehen. Das ist eine weitere erklärungsbedürftige Abweichung, kein Beweis für einen bestimmten Abrechnungsfehler.[1]
Der Kunde berichtete, beim Versuch einer Statusänderung sei ein Fehler wegen eines abgelaufenen Dienstes erschienen. Das beigefügte Fehlerbild lässt nicht erkennen, welcher Server ausgewählt war. Zugehörige API-Anfragen lieferten ebenfalls Fehler wegen abgelaufener Dienste. Beide VPS waren bei der letzten Prüfung weiterhin aufgeführt.[11] Ihre fortbestehende Präsenz im Konto unterscheidet diese abgelaufenen Dienste vom früheren Verschwinden. Eine Löschung der beiden späteren VPS wurde nicht nachgewiesen. Die Beobachtungen bestimmen weder den genauen Stoppzeitpunkt noch belegen sie eine durchgehende Ausfallzeit, Datenverlust oder Störungen für Endkunden.
Worauf ein Unternehmen sich verlassen können muss
OVHcloud unterscheidet in seinen öffentlichen Hinweisen zwischen automatischer und manueller Verlängerung und erläutert die Rolle einer hinterlegten Zahlungsmethode. Die Abrechnungshinweise nennen auch eine Sperrung bei ausbleibender Zahlung. Diese Unterscheidungen unterstreichen, dass eine Verlängerungseinstellung und ein abgeschlossener Abrechnungsvorgang getrennt betrachtet werden müssen. Sie erklären nicht, was in diesem Konto geschah.[12]
Die offenen Fragen sind konkret. Wurde eine Verlängerungsrechnung erstellt? Gab es einen Zahlungsversuch, und mit welchem Ergebnis? Warum nannten Hinweise zur manuellen Verlängerung Dienste, die auf automatische Verlängerung eingestellt waren? Welche Bestätigung meinte der Support angesichts der VPS-Ausnahme im Banner? Welches Ereignis führte zur Entfernung des früheren Servers, und welche Wiederherstellungsmöglichkeiten bestanden noch?
Für die Unternehmensplanung bedeutet verlässliche Hosting-Verwaltung, dass solche Fragen vor einer Frist so beantwortet werden, dass sich daraus konkrete Schritte ableiten lassen. Ein Kunde muss wissen, wer handeln muss, was zu tun ist und wie die Erledigung bestätigt wird. Ein eindeutiger Verlängerungsstatus, eine fortgeschriebene Laufzeit und ein nachvollziehbares Zahlungsergebnis bieten mehr Sicherheit als eine Einstellung allein.
Der Fall zeigt auch, warum Berater zwischen einer Konfigurationsprüfung und der Kontrolle einer abgeschlossenen Verlängerung unterscheiden und zugesagte Nachprüfungen dokumentieren müssen. Die Belege rechtfertigen Kritik an widersprüchlichen Informationen und einem ungeklärten Supportaustausch. Sie weisen weder den zugrunde liegenden Fehlermechanismus nach noch rechtfertigen sie ein pauschales Urteil über OVHclouds Betrieb in Zürich.
Wir schätzen die Produkte von OVHcloud und betrachten das Unternehmen als leistungsfähigen Anbieter. Unsere Bedenken zu diesem Zürcher Fall bestehen neben dieser positiven Einschätzung. Die Unterlagen lassen praktische Fragen offen: wie automatische Verlängerung in fortgesetzte Verfügbarkeit mündet, welche Bestätigung ein Kunde erteilen muss und wie der Support die erforderlichen Schritte vermittelt. Diese Punkte bedürfen der Klärung und, wo sich Mängel bestätigen, der Verbesserung. Unternehmen müssen aus den Informationen in ihrem Konto verlässliche betriebliche Entscheidungen ableiten können.
Die praktische Sorge bleibt: Ein Unternehmen kann nicht verlässlich mit einem Server planen, wenn die verfügbaren Informationen offenlassen, ob sein Erhalt weitere Schritte erfordert. Diese Unsicherheit aufzulösen, gehört zu einem zuverlässigen Dienst.
Überprüfen Sie Ihre Hosting-Lösung? Sprechen Sie mit unserem Engineering-Team über Abhängigkeiten, Zuständigkeiten für Verlängerungen und Wiederherstellungsplanung.
Quellenhinweise
Geprüft wurden private Kontounterlagen und Korrespondenz mit Belegstand 30. Oktober 2026. Die Originale werden vertraulich aufbewahrt. Diese Hinweise beschreiben ihre Beweisfunktion, ohne identifizierende Angaben zu veröffentlichen. Historische Ticket- und Mitteilungsseiten wurden am 30. Oktober im Browser erfasst, nicht an den jeweiligen Nachrichtendaten. Die genauen Aufnahmezeiten der vom Kunden bereitgestellten Screenshots sind unbekannt. Dies ist eine Auswertung der vorgelegten Unterlagen, keine vollständige Prüfung der Anbietersysteme oder sämtlicher Kundenkommunikation.
- Vorher und nachher. Gespeicherte API-Antworten und ein am 23. Oktober bereitgestellter Screenshot; am 30. Oktober erhaltene Kundenscreenshots; letzte API-Prüfung am 30. Oktober. Laufend/OK wurde zu gestoppt/abgelaufen; automatische Verlängerung und Ablaufdatum blieben bestehen. Der frühere Screenshot dokumentiert auch Bannerwortlaut und Angaben zur Vertragsbindung.
- Früheres Verschwinden. Serverinventar vom 2. Oktober, zeitgenössische Aufzeichnung der vom Nutzer bestätigten Löschung sowie API-Antworten vom 8. und 30. Oktober, wonach der Dienst nicht existierte. Ursache und genauer Löschzeitpunkt sind unbestätigt.
- Frühere Verlängerungseinstellung und Beratung. API-Antwort vom 10. September; weitergeleitete Erinnerung zur manuellen Verlängerung und Antwort des Beraters vom 17. September.
- Separater technischer Fall. Verlauf des Performance-Tickets vom September und aufbewahrte Diagnosedaten, einschließlich Erstmeldung und späterer Meldung der Neustartverzögerung. Kein nachgewiesener Zusammenhang mit Verlängerung oder Löschung.
- Verlängerungsprüfungen. Erste und nachfolgende API-Erfassungen vom 2. Oktober, wiederholte Erfassungen vom 8. Oktober, eine wiedergefundene API-Zusammenfassung vom 20. Oktober sowie Rohantworten vom 23. Oktober. Die ursprüngliche vollständige API-Datei vom 20. Oktober lag nicht vor.
- Grenzen der Zahlungsbelege. Beobachtung im Verwaltungsportal und Supportanfrage vom 8. Oktober. Eine gespeicherte Standardzahlungsmethode und frühere bezahlte Rechnungen belegen nicht die Begleichung der späteren Verlängerung.
- Erstes Verlängerungsticket. Eröffnungsanfrage vom 8. Oktober; erste sichtbare Antwort eines Supportmitarbeiters vom 23. Oktober; Systemnachricht vom 26. Oktober; Widerspruch des Kunden und Wiederherstellungsanfrage vom 30. Oktober. Die Zeitzonen der angezeigten Ticketzeiten sind unbestätigt.
- Schließung als Duplikat. Zweites Ticket vom 21. Oktober mit ergänzendem Anhang; am 23. Oktober als Duplikat geschlossen.
- Verlängerungserinnerungen. Historische Mitteilungen vom 23. und 24. Oktober, einschließlich der Einträge für Basisserver und Optionen.
- Zusicherung des Beraters. Versandte E-Mails vom 20. und 23. Oktober; letztere kündigt eine Nachprüfung am 24. Oktober an. In den vorgelegten Unterlagen wurde keine abgeschlossene Nachprüfung gefunden.
- Fehler bei abgelaufenen Diensten. Kunden-E-Mail und Fehleranhang vom 30. Oktober; API-Antworten vom selben Tag und abschließendes Serverinventar. Der Fehler-Screenshot allein identifiziert den ausgewählten VPS nicht.
- Öffentliche Anbieterinformationen. OVHcloud, How to renew OVHcloud services und Billing and payment FAQ, abgerufen am 30. Oktober 2026. Allgemeine Hinweise, keine kontospezifische Feststellung oder Bestimmung der anwendbaren Vertragsbedingungen.
