Service Level Agreement

1. Toepassingsgebied

Deze Service Level Agreement ("SLA") is door middel van verwijzing opgenomen in de Servicevoorwaarden en regelt de service-level-verplichtingen die we aangaan jegens klanten die gebruikmaken van de hieronder beschreven Diensten.

1.1 Gedekte diensten

Deze SLA is van toepassing op de volgende categorieën Diensten:

• Virtuele privéservers (VPS), inclusief alle Linux KVM-tiers
• Remote Desktop Protocol-servers (RDP)
• Dedicated servers (DS)
• GPU-servers (GPU)
• Opslag- en back-upservers
• Streaming-servers
• Game-servers

1.2 Diensten met aangepaste verplichtingen

Shared- en cPanel-hosting dragen de uptime-verplichtingen uit Sectie 2, maar met een meting die is aangepast aan de architectuur van het shared-tier (het relevante meetdoel is de beschikbaarheid van de shared host in plaats van de beschikbaarheid van de container per klant).

1.3 Niet gedekte diensten

E-mail- en SMTP-hosting dragen afzonderlijke beschikbaarheidsverplichtingen die zijn gepubliceerd op hun respectievelijke productpagina's. Bèta- en preview-diensten die expliciet als zodanig zijn gelabeld, vallen niet onder deze SLA.

2. Uptime-verplichting

2.1 Standaardplannen

Standaardplannen - VPS-1 tot en met VPS-8, RDP-Basic en RDP-Pro, alle opslag-tiers, Game-S en Game-M, Streaming-1 - dragen een maandelijkse uptime-verplichting van 99,9%.

Een maandelijkse uptime van 99,9% komt overeen met maximaal 43 minuten en 50 seconden downtime in een kalendermaand van 30 dagen, of 44 minuten en 38 seconden in een maand van 31 dagen.

2.2 Pro-, Premium-, Dedicated- en GPU-plannen

Plannen in hogere tiers - VPS-16, RDP-Power, alle Dedicated-tiers (DS-Lite tot en met DS-Beast), alle GPU-tiers (GPU-Lite tot en met GPU-Beast), Game-L, Streaming-2 - dragen een maandelijkse uptime-verplichting van 99,99%.

Een maandelijkse uptime van 99,99% komt overeen met maximaal 4 minuten en 23 seconden downtime in een kalendermaand van 30 dagen, of 4 minuten en 28 seconden in een maand van 31 dagen.

3. Meetmethodologie

3.1 Externe monitoring

Uptime wordt gemeten door externe monitoringnodes die worden beheerd door externe uptime-providers (UptimeRobot, Better Uptime of vergelijkbaar). We onderhouden momenteel drie (3) onafhankelijke monitoringnodes in geografisch verschillende regio's om meting met een single point of failure te voorkomen.

3.2 Probe-interval

Elke monitoringnode test het primaire eindpunt van elke Dienst elke vijf (5) minuten.

3.3 Meerderheidsdetectie

Downtime wordt geregistreerd wanneer ten minste twee van de drie monitoringnodes de Dienst als onbereikbaar rapporteren in hetzelfde probe-venster. Dit voorkomt dat lokale netwerkstoringen bij de monitoringnode worden toegeschreven aan een MurmurHost-incident.

3.4 Opbouw van downtime

Een "downtimeminute" is elke hele minuut waarin de meerderheidsdetectie in de onbereikbare staat verkeert. Gedeeltelijke minuten worden naar boven afgerond op hele minuten voor de berekening van credits.

3.5 Meting aan klantzijde

Klanten kunnen hun eigen monitoringinfrastructuur gebruiken om downtimeclaims te onderbouwen. Waar meting aan klantzijde materieel afwijkt van onze monitoring, delen we onze meetgegevens en werken we toe naar overeenstemming over de werkelijke downtimeperiode.

4. Service Credits

4.1 Credit-tiers

Als een gedekte Dienst onder zijn maandelijkse uptime-verplichting zakt, heeft de klant recht op een service credit, berekend als een percentage van de maandelijkse vergoeding voor de betreffende Dienst:

4.2 Toepassing

Service credits worden toegepast op de volgende factuur van de betreffende Dienst. Als de klant de betreffende Dienst beëindigt vóór de volgende factuur, wordt de credit uitbetaald als terugbetaling via de oorspronkelijke betaalmethode, onderworpen aan de verwerkingstermijnen in het Restitutiebeleid.

4.3 Maximum

Het totale credit voor een betreffende Dienst in een enkele maand kan niet hoger zijn dan 100% van de maandelijkse vergoeding van die Dienst. Service credits zijn het enige en exclusieve rechtsmiddel van de klant voor het niet nakomen van uptime-verplichtingen onder deze SLA.

5. Uitsluitingen

Het volgende telt niet als downtime voor de doeleinden van Sectie 2:

5.1 Gepland onderhoud

Onderhoud dat ten minste achtenveertig (48) uur van tevoren is aangekondigd via het klantenportaal en de statuspagina op /status. Routinematige onderhoudsvensters worden doorgaans gepland buiten de piekuren voor de betreffende jurisdictie.

5.2 Overmacht

Natuurrampen, oorlog, burgerlijke onrust, overheidsoptreden, terrorisme of vergelijkbare gebeurtenissen buiten onze redelijke controle.

5.3 Fout van de klant

Downtime veroorzaakt door verkeerde configuratie door de klant, softwarefouten die onder controle van de klant vallen, overschrijding van de resource-allocaties van het plan, of handelingen die door de klant zijn uitgevoerd (zoals vrijwillige herstart, herinstallatie van het besturingssysteem of configuratiewijziging die externe toegang uitschakelt).

5.4 Storingen in netwerken van derden

Downtime veroorzaakt door storingen in netwerken van derden buiten ons netwerk en buiten onze peering-overeenkomsten, inclusief storingen in de eigen ISP van de klant, transitprovider of last-mile-netwerk.

5.5 Actie op grond van de AUP

Opschorting onder de AUP telt niet als downtime. Betwiste AUP-opschortingen die in beroep worden teruggedraaid, worden niet met terugwerkende kracht als downtime geteld; het rechtsmiddel van de klant in dat geval is gedocumenteerd in de AUP.

6. Netwerkprestaties

6.1 Latentie-doelstellingen

We committeren ons aan mediane latentiedoelstellingen tussen ons edge-netwerk en de belangrijkste regionale internetknooppunten, maandelijks gemeten:

6.2 Pakketverlies

We committeren ons aan minder dan 0,1% pakketverlies op intra-datacenterverkeer, gemeten over een willekeurig voortschrijdend venster van 5 minuten, exclusief intervallen die worden beïnvloed door actieve DDoS-scrubbing.

6.3 Doorvoer

We committeren ons aan doorvoer op de poortsnelheid die op de Dienst is geconfigureerd, minus de typische encapsulatie- en transito-overhead. Aanhoudende doorvoer die materieel onder de poortsnelheid ligt (na uitsluiting van transito-congestie buiten ons netwerk) wordt behandeld als een misser op netwerkprestaties.

7. DDoS-mitigatietiming

7.1 Volumetrische aanvallen

Volumetrische DDoS-aanvallen gericht op klantdiensten worden gedetecteerd en getagd door onze anycast-scrubbing-edge binnen zestig (60) seconden na het begin van de aanval. Mitigatie is automatisch en vereist geen actie van de klant.

7.2 Applicatielaag-aanvallen

Aanvallen op de applicatielaag (L7) vereisen applicatiespecifieke regels. We bieden standaardregels aan de edge voor veelvoorkomende patronen; regels die zijn afgestemd op de specifieke applicatie van de klant (URL-paden, verzoeksignaturen) zijn de verantwoordelijkheid van de klant, optioneel configureerbaar via Cloudflare of BunnyCDN aan de applicatie-edge.

7.3 Capaciteit per plantier

Volumetrische scrubbingcapaciteit schaalt met de plantier en is gedocumenteerd op /features/ddos-protection. Aanhoudende aanvallen boven de scrubbingcapaciteit van het plan kunnen leiden tot een gesprek over een upgrade in plaats van een service credit.

8. Provisioning-SLA

8.1 KVM-gebaseerde diensten

KVM-VPS-, RDP-, shared- en cPanel-plannen voltooien de provisioning binnen vijf (5) minuten na betalingsbevestiging. Bevestiging is het moment waarop de cryptocurrency-betaling de drempelbevestigingen bereikt die zijn beschreven op de relevante betaalmethode-pagina; voor kaartbetalingen waar ondersteund, is bevestiging de afwikkeling bij de processor.

8.2 Dedicated en GPU

Standaard dedicated- en GPU-plannen voltooien de provisioning binnen vierentwintig (24) uur na betalingsbevestiging. Aangepaste dedicated-builds (multi-GPU, exotische RAID-configuraties, specifieke NIC-modellen) worden gemarkeerd bij het plaatsen van de bestelling en kunnen 1-3 werkdagen duren.

8.3 Bulkbestellingen

Bulkbestellingen (meer dan vijf Diensten in één transactie) vereisen coördinatie met het verkoopteam. Doorlooptijden worden overeengekomen bij het plaatsen van de bestelling en maken deel uit van de orderspecifieke SLA.

8.4 Credits voor provisioning-missers

Als de provisioning het relevante doel met meer dan 25% overschrijdt, heeft de klant recht op een service credit voor één maand op de betreffende Dienst. Dit is aanvullend op eventuele uptime-gerelateerde credits die onder Sectie 4 ontstaan.

9. Reactietijden ondersteuning

9.1 Ernstdefinities

• Kritiek: server down, gegevens niet toegankelijk, beveiligingsincident gaande
• Hoog: verminderde prestaties, gedeeltelijke uitval, intermitterende onbereikbaarheid
• Normaal: configuratievraag, functievraag, factureringsverduidelijking die de servicewerking niet beïnvloedt
• Laag: documentatiefeedback, procesvraag, niet-tijdgevoelig verzoek

9.2 Reactiedoelstellingen

9.3 Ondersteuningskanalen

Tickets worden geaccepteerd via het klantenportaal en per e-mail naar [email protected]. De 24/7 chat (waar beschikbaar, lazy-loaded volgens de documentatie in /features) is voor algemene vragen; problemen met ernst Kritiek moeten altijd ook als ticket worden geopend om tracking te garanderen.

10. Credits claimen

10.1 Claimvenster

Service credits moeten worden geclaimd binnen dertig (30) dagen na het incident dat aanleiding gaf tot de credit. Credits die niet binnen dit venster worden geclaimd, vervallen.

10.2 Claimprocedure

Om een credit te claimen, stuurt u een e-mail naar [email protected] met de volgende informatie:

• Account-e-mail en identificatie van de betreffende Dienst
• Datum en tijd van het incident in UTC
• Reden voor de claim (uptime-misser, provisioning-misser, netwerkprestatie-misser)
• Eventuele externe monitoringsgegevens die de klant heeft ter onderbouwing van het incident

10.3 Verwerking

We bevestigen claims binnen achtenveertig (48) uur. Een inhoudelijke oplossing wordt doorgaans binnen zeven (7) werkdagen voltooid. Goedgekeurde credits worden toegepast op de volgende factuur of, op verzoek van de klant, uitbetaald als terugbetaling volgens Sectie 4.2.

11. Onderhoudsvensters

Onderhoudsadviezen worden gepubliceerd op de statuspagina op /status en per e-mail verzonden aan alle getroffen klanten. Het standaard adviesvenster is achtenveertig (48) uur. Spoedeisend onderhoud - vereist om een actief beveiligings- of stabiliteitsprobleem aan te pakken - kan worden uitgevoerd zonder voorafgaand advies; in dat geval wordt binnen vijf (5) werkdagen een post-mortem gepubliceerd op de statuspagina.

12. Wijzigingen in deze SLA

We kunnen deze SLA periodiek bijwerken. Materiële wijzigingen die het niveau van de onder deze SLA gegarandeerde service verlagen, vereisen dertig (30) dagen kennisgeving via de procedure in Servicevoorwaarden Sectie 15. Wijzigingen die verplichtingen verbeteren of taal verduidelijken, worden onmiddellijk van kracht bij publicatie. De datum "Laatst bijgewerkt" bovenaan dit document weerspiegelt de meest recente wijziging.