Oppetid og SLA – hva betyr 99,9 prosent i praksis?

«99,9 prosent oppetid» høres presist ut. Uten målepunkt, periode, unntak og konsekvens er tallet likevel vanskelig å bruke. Det kan være markedsføring, historisk måling, internt mål eller en kontraktsfestet garanti – fire forskjellige ting.

Denne guiden viser hvordan dere regner om prosent til nedetid og leser en hosting-SLA før dere velger leverandør.

Oppetid, tilgjengelighet og SLA er ikke det samme

• Oppetid beskriver ofte hvor lenge en server, tjeneste eller komponent har vært i drift.
• Tilgjengelighet handler om hvor stor del av tiden brukeren faktisk kan gjennomføre en definert handling.
• Målt historikk viser hva en monitor observerte i en tidligere periode.
• Målsetting sier hva leverandøren forsøker å oppnå, uten nødvendigvis å gi kunden et krav.
• SLA er en avtale om tjenestenivå med definisjon, måling, unntak, ansvar og vanligvis en reaksjon ved brudd.

En webserver kan svare med status 200 samtidig som innlogging, database, skjema eller betaling er nede. Høy serveroppetid er derfor ikke automatisk høy tilgjengelighet for kundens viktigste brukerreise.

Regn om prosent til nedetid

Formelen er:

Tillatt nedetid = måleperiode × (1 − oppetidsprosent)

Tabellen bruker en måned på nøyaktig 30 dager og et år på 365 dager. En avtale kan bruke kalendermåned, rullerende periode eller en annen nevner.

To korte utfall og ett langt utfall kan gi samme prosent, men ha ulik forretningskonsekvens. Ti minutter under lønnskjøring eller en kampanje kan være dyrere enn to timer om natten.

Finn hva prosenttallet gjelder

Spør hvilket målepunkt som faktisk inngår:

For en enkel informasjonsside kan en kontroll av riktig HTTP-status og forventet innhold være tilstrekkelig. For en nettbutikk bør målingen også dekke produktvisning, handlekurv, betalingens avhengigheter og ordreopprettelse uten å gjennomføre falske kjøp.

Hele kjeden må virke

Nettsiden kan bli utilgjengelig selv om hostingleverandørens server er frisk:

• domenet er suspendert eller ikke fornyet
• autoritative navnetjenere svarer ikke
• DNSSEC har feil DS-kobling
• CDN eller proxy feiler
• TLS-sertifikatet er utløpt eller feil for navnet
• applikasjon, database eller cache er nede
• innlogging eller identitetsleverandør feiler
• betalings-, kart- eller skjematjeneste er utilgjengelig
• feil konfigurasjon blir publisert

Avklar om SLA-en dekker bare én komponent eller den kundevendte tjenesten. Hvis DNS, database, backup eller tredjepart ligger utenfor, må virksomhetens egen tilgjengelighetsplan dekke gapet.

Les målemetoden før prosenttallet

En brukbar definisjon svarer på:

Hvor måles det fra?

Én monitor i samme datasenter kan overse regionale nettverksproblemer. Flere uavhengige målepunkter reduserer faren for at en lokal monitorfeil blir registrert som nedetid, eller at et regionalt utfall ikke oppdages.

Hvor ofte måles det?

Et intervall på fem minutter kan overse korte utfall. Et intervall på ti sekunder gir mer data, men kan også fange kortvarig støy. Avtalen bør si hvordan delintervaller og timeout behandles.

Hva regnes som feil?

Definer forventet protokoll, status, svartid og innhold. Et tomt svar med 200 er ikke nødvendigvis tilgjengelig. En treg side kan være kommersielt ubrukelig lenge før den gir timeout.

Hvor mange feil kreves?

Noen systemer krever flere sammenhengende feil eller svikt fra flere regioner før en hendelse starter. Det reduserer falske alarmer, men kan skjule korte reelle utfall.

Når starter og slutter hendelsen?

Er det første feilede måling, kundens varsel, leverandørens bekreftelse eller en intern alarm? Forskjellen kan være betydelig i en kompensasjonsberegning.

Hvilken periode brukes?

En kalendermåned nullstiller regnestykket hver måned. En rullerende 30-dagersperiode oppfører seg annerledes. Årlig måling kan skjule en svært dårlig enkeltmåned bak resten av året.

Undersøk unntakene

Vanlige unntak kan være:

• varslet vedlikehold
• nødvedlikehold
• kundens kode, konfigurasjon eller DNS
• tredjepartsleverandører
• DDoS og andre angrep
• force majeure
• overskredet ressurs- eller trafikkgrense
• manglende betaling eller brudd på vilkår
• beta- og gratistjenester

Et unntak kan være rimelig, men det må passe risikoen deres. Hvis alt fra DNS og database til sikkerhetshendelser er unntatt, kan garantien dekke svært lite av den reelle nedetiden.

Spør også om planlagt vedlikehold trekkes helt ut av nevneren, om det har maksimal varighet, hvor tidlig det varsles, og om kritisk vedlikehold kan skje uten varsel.

Se på kompensasjonen

En SLA gir ofte tjenestekreditt, ikke erstatning for tapt omsetning. Kontroller:

• hvor stor kreditten er ved hvert nivå
• om den gjelder månedens pris eller hele avtalen
• om kunden må kreve den innen en kort frist
• hvilken dokumentasjon som kreves
• om kreditten er eneste misligholdsbeføyelse
• om indirekte tap og datatap er uttrykkelig unntatt
• om samlet ansvar har et lavt tak

Et webhotell til 49 kroner per måned med 10 prosent tjenestekreditt gir 4,90 kroner. Det er ikke økonomisk beskyttelse for en kritisk nettbutikk. SLA-en kan fortsatt være nyttig fordi den gjør måling og ansvar tydelig, men beredskap, arkitektur og forsikring må håndtere den faktiske konsekvensen.

Oppetid sier ikke hvor raskt dere får hjelp

Be om separate mål for:

• responstid: når en kvalifisert person begynner å behandle saken
• oppdateringsfrekvens: hvor ofte kunden får ny status
• gjenopprettingstid: mål eller garanti for å få tjenesten tilbake
• RTO: virksomhetens maksimalt akseptable tid til gjenoppretting
• RPO: maksimalt akseptabelt datatap målt i tid
• eskalering: hva som skjer når fristen brytes

En 99,99-prosent SLA hjelper lite hvis en kritisk feil bare kan meldes i et skjema som leses neste virkedag. Omvendt kan tydelig respons og god gjenoppretting være mer verdifullt enn en litt høyere prosent uten praktisk støtte.

Oppetid er heller ikke dataintegritet

Et nettsted kan være «oppe» mens det viser feil data, mangler nye ordre eller kjører på en korrupt database. Avklar hvordan leverandøren håndterer:

• backupomfang og oppbevaring
• konsistens mellom filer og database
• kundens mulighet til å gjenopprette
• tid og pris for restore
• test av gjenoppretting
• data som opprettes mens feil eller flytting pågår

Les hva en gjenopprettbar nettsidebackup krever før backup brukes som argument for tilgjengelighet.

Mål selv, men mål riktig

Uavhengig overvåking gir et kundeperspektiv og dokumentasjon ved uenighet. Sett opp:

1. en enkel tilgjengelighetstest fra flere relevante regioner
2. innholdskontroll som viser at riktig side kom tilbake
3. egne tester for kritiske brukerreiser
4. DNS-, DNSSEC- og sertifikatovervåking
5. varsling i en kanal som ikke avhenger av samme domene
6. en status- og hendelseslogg med tidssone

Unngå å sende kundeopplysninger eller gjennomføre virkelige betalinger i syntetiske tester. Bruk egne testkontoer og dokumenterte transaksjonsløp.

Måling fra ett sted er observasjon, ikke nødvendigvis sannheten. Bekreft større avvik fra flere kilder før risikofylte endringer gjøres.

Bruk feilbudsjett i drift

En tilgjengelighetsmålsetting kan gjøres om til et feilbudsjett. Med 99,9 prosent per 30 dager er budsjettet 43 minutter og 12 sekunder. Hvert relevant utfall bruker av dette.

Feilbudsjettet kan styre beslutninger:

• Når budsjettet er nesten brukt, prioriteres stabilisering foran risikable funksjonslanseringer.
• Planlagte endringer får tydelig rollback og observasjonsperiode.
• Gjentatte små utfall behandles som mønster, ikke isolerte supportsaker.
• Målet revurderes hvis produktets reelle konsekvens har endret seg.

Dette er intern risikostyring. Det endrer ikke automatisk leverandørens kontraktsberegning.

Sammenlign leverandører på samme grunnlag

Bruk denne listen:

Sammenlign den konkrete avtalen og pakken dere skal kjøpe. En leverandør kan ha én SLA for VPS, en annen for administrert plattform og ingen garanti på rimelig webhotell.

Hva konkurrentene publiserer

Per 22. august 2026 viser Uniwebs hostingside 99,98 prosent oppetid. Tallet tilsvarer omtrent 8 minutter og 38 sekunder nedetid i en 30-dagersperiode. Før det behandles som en garanti, må kunden fortsatt finne målemetode, avgrensning, unntak og kompensasjon for den valgte pakken.

Webhusets generelle vilkår sier at de har som mål at tjenestene skal være tilgjengelige hele døgnet, men ikke garanterer uavbrutt drift. Vilkårene beskriver også et nattlig vedlikeholdsvindu og informasjon om vesentlige driftsforstyrrelser.

Dette viser hvorfor en stor prosent på produktsiden og tydelige vilkår må leses sammen. Vymo bør ikke kalle et mål for en garanti, og konkurrenter bør vurderes etter avtaleteksten – ikke bare kortet på prissiden.

Vymos enkle nettside har ingen publisert SLA

Vymo publiserer ikke en oppetidsprosent, tilgjengelighetsgaranti, garantert responstid eller ordning med tjenestekreditt for den enkle nettsiden. Vi skal derfor ikke omtale løsningen som «99,9 prosent», «alltid tilgjengelig» eller SLA-dekket.

Tilbudet gjelder én enkel bedriftsside som Vymo setter opp og hoster. Hosting er inkludert de første 12 månedene og koster deretter fra 49 kroner per måned, fakturert årlig. Tjenesten er ikke ment som standardløsning for nettbutikk, booking, betaling eller andre kritiske transaksjoner.

Hvis virksomheten trenger kontraktsfestet tilgjengelighet, responstid, gjenoppretting, statusrapportering eller kompensasjon, må det avklares som en annen eller særskilt leveranse før bestilling. Ikke legg et kritisk krav til grunn fordi nettsiden bruker Cloudflare eller HTTPS; underleverandørens infrastruktur blir ikke automatisk en SLA mellom Vymo og kunden.

For en vanlig presentasjonsside bør virksomheten likevel ha en enkel plan for å oppdage feil og kontakte Vymo gjennom en kanal som virker. Bruk guiden når nettstedet er nede og beredskapsplanen for domene, DNS og e-post .

Velger dere webhotell for en større løsning, bruk den komplette sjekklisten for webhotell og driftsansvar .