Als de cloud-API beheer blokkeert
Een storing in de Hetzner Cloud API en Console voorkwam op 6 oktober gedurende 103 minuten bepaalde resource-acties. Niet iedere gehoste applicatie werd daardoor onbereikbaar. De storing legde wel een belangrijkere vraag bloot: wie onderscheidt providerproblemen van applicatiefouten en blijft veilig handelen wanneer het control plane hapert?
- Auteur
- Intercube
- Gepubliceerd
- Leestijd
- 8 min leestijd
01
Wat er op 6 oktober gebeurde
Hetzner meldde op 6 oktober 2026 tussen 08:20 en 10:03 UTC een storing in de Cloud API en Console. Door onjuiste limietberekeningen werkten sommige handelingen niet, waaronder het aanmaken en verplaatsen van resources. De provider noemde load balancers, netwerken, cloudservers, object storage en cloudvolumes als betrokken systemen en bevestigde daarna dat het probleem was opgelost.
De melding beschrijft mislukte handelingen in het control plane. Ze stelt niet dat iedere draaiende server of website offline ging. Dat onderscheid is belangrijk. Een applicatie kan verkeer blijven verwerken terwijl operators tijdelijk geen capaciteit kunnen aanmaken, netwerken kunnen wijzigen of een herstelactie via de provider-API kunnen uitvoeren.
De praktische impact hangt daarom af van wat de applicatie in die 103 minuten nodig had. Een stabiele workload vroeg mogelijk geen wijziging. Een deployment, schaalactie, disaster-recoveryhandeling of infrastructuurmigratie kon precies op het verkeerde moment tegen een geblokkeerde actie aanlopen.
02
Uitval van het control plane verandert veilig beheer
Wanneer het control plane van een provider hapert, kan herhaalde automatisering de diagnose moeilijker maken. Mislukte create- of move-acties kunnen duidelijk worden geweigerd, vertraagd raken of gedeeltelijk in lokale state terechtkomen. Operators moeten niet-essentiële wijzigingen pauzeren, de providerstatus beoordelen, echte resources met infrastructuurstate vergelijken en pas opnieuw proberen wanneer de uitkomst van de eerste aanvraag bekend is.
Herstelplannen moeten ook rekening houden met de beschikbaarheid van de gereedschappen waarmee zij worden uitgevoerd. Een snapshot of back-up helpt pas wanneer het team deze kan vinden, weet welke data erin zit en via een beschikbaar pad kan herstellen. Hetzner documenteert dat serverback-ups en snapshots een kopie van de serverdisk maken, maar gekoppelde volumes niet meenemen. Dat vraagt herstelplanning met kennis van de applicatie.
Daarom horen providerstatus, applicatiegezondheid en deploymentstate in één incidentbeeld. Zonder die context kan een team het eerste deel van een incident in de eigen code zoeken, of infrastructuurwijzigingen starten die niet kunnen afronden zolang de provider-API onbereikbaar is.
- Scheid applicatiebeschikbaarheid van beschikbaarheid van het provider-control plane.
- Pauzeer niet-essentiële automatisering totdat mislukte acties een bekende uitkomst hebben.
- Vergelijk infrastructuurstate met echte resources voordat create-, move- of netwerkwijzigingen opnieuw lopen.
- Test herstel met iedere datastore en elk gekoppeld volume binnen de scope.
03
Een cloudaccount levert geen operator
Cloudproviders beheren fysieke infrastructuur en hun eigen control planes. De klant blijft verantwoordelijk voor applicatiearchitectuur, deploymentgedrag, providerspecifieke automatisering, monitoring, back-ups en besluitvorming tijdens een incident. Een goedkope cloudserver bevat geen operator die begrijpt wat een mislukte provideractie betekent voor een orderflow, queue of database.
Die kloof blijft vaak verborgen zolang alles gezond is. Zij verschijnt wanneer een release samenvalt met providerproblemen, capaciteit snel moet veranderen of herstel afhankelijk is van een resource-actie die tijdelijk niet beschikbaar is. Ontwikkelaars worden dan het infrastructuurresponsteam, ook wanneer dat werk nooit onderdeel van de productplanning was.
Een managed hosting-relatie maakt de grens expliciet. Het applicatieteam bezit de applicatie en releases. De operator bezit de diepere infrastructuurlifecycle, volgt providerincidenten, beschermt routinematige wijzigingen en coördineert herstel met kennis van de echte workload.
04
Verplaats de beheerlast, niet alleen de server
Van infrastructuurprovider veranderen verwijdert deze verantwoordelijkheid niet. Iedere provider kent onderhoudsvensters, quota, service-incidenten en foutdomeinen. De duurzame verbetering is ontwerpen rond de applicatie, herhaalbare handelingen automatiseren en een operator aanwijzen die zowel de provider als de workload begrijpt.
Intercube levert die managed laag. Wij provisionen en onderhouden de infrastructuur, koppelen deployments, bewaken het platform en voeren provideroperaties uit terwijl het klantteam controle houdt over code en releases. Wanneer een onderliggende dienst een incident heeft, heeft de klant één technische partij die dit vertaalt naar applicatie-impact en actie.
Als een team nu zelf verantwoordelijk is voor een los cloudaccount, is migratie naar Intercube managed hosting inbegrepen zonder aanvullende kosten binnen de afgesproken onboardingscope. De verhuizing omvat de doelomgeving, overdracht van applicatie en data, deploymentvoorbereiding, productieomschakeling en terugvalplanning waar de workload dat vraagt.
Wat dit incident moet losmaken
- Breng in kaart welke deployment- en herstelacties van het provider-control plane afhangen.
- Bevestig dat back-ups gekoppelde data afdekken en via een getest pad kunnen herstellen.
- Bepaal hoe automatisering pauzeert en state vergelijkt na onzekere provideracties.
- Geef één operator verantwoordelijkheid voor infrastructuur, monitoring en herstel.
- Verhuis naar managed hosting wanneer cloudbeheer telkens bij ontwikkelaars terechtkomt.