Dit site er lige gået ned. Hvornår skete det? Hvem opdagede det først — dig, eller en frustreret kunde, der skrev om det på sociale medier?
Uptime monitoring sørger for, at svaret altid er dig, og at du finder ud af det inden for minutter, ikke timer. Denne guide forklarer, hvordan det fungerer, hvad du bør måle ud over simple HTTP checks, og hvordan du konfigurerer alerts, der faktisk hjælper i stedet for bare at skabe støj.
Hvad er uptime monitoring?
Uptime monitoring er den praksis løbende og automatisk at tjekke, om et website eller en tjeneste er tilgængelig og returnerer det forventede svar. En monitor sender HTTP requests til din URL med faste intervaller — typisk hvert 1 til 5 minut — og registrerer resultatet: oppe, nede eller forringet.
Når et check fejler, sendes en alert med det samme via email, SMS, Slack eller webhook, så ejeren af sitet kan undersøge og reagere.
Hvorfor uptime betyder mere, end du tror
Indvirkning på omsætning
For e-commerce-sites betyder downtime direkte tabte salg. Amazon har offentligt estimeret tab på ~$220.000 per minuts nedbrud. Selv for små webshops kan en times downtime i spidsbelastningstiden udslette en hel dags omsætning.
Indvirkning på SEO
Googlebot crawler dit site løbende. Hvis den gentagne gange støder på fejl (500, timeout), reducerer den din crawl rate og kan midlertidigt sænke dine placeringer. Længerevarende nedbrud kan udløse manuel gennemgang. Det tager længere tid at komme sig end selve nedbruddet varer.
Brugertillid
Brugere, der rammer en fejlside, kommer sjældent tilbage. Undersøgelser viser konsekvent, at tilgængelighed er vigtigere end enhver anden kvalitetsindikator for førstegangsbesøgende. En status page, der viser en kendt hændelse, er langt bedre end en tavs fejl.
Sådan fungerer uptime monitoring
Det grundlæggende HTTP check
Den simpleste monitor sender en HTTP GET request til en URL og tjekker:
- Svarede serveren? (TCP connection)
- Svarede den inden for en timeout? (f.eks. 30 sekunder)
- Returnerede den en acceptabel status code? (typisk 200–299)
Hvis en af betingelserne fejler, registreres checket som "nede."
Mere end status codes
Et simpelt 200-svar garanterer ikke et fungerende site. Typiske fejlsituationer, der returnerer 200:
- En vedligeholdelsesside, der erstatter den rigtige app
- En cached eller CDN-serveret forældet side, mens origin er nede
- En blank side på grund af en JavaScript-fejl
- En databasefejl, der stille og roligt renderer tomt indhold
Mere avancerede checks tilføjer keyword matching — verificering af, at en bestemt streng (f.eks. et produktnavn, et navigationselement) er til stede i response body.
Multi-location checks
Et check fra en enkelt lokation kan snydes af:
- Regionale netværksproblemer (din monitors datacenter kører, men dine brugere i Tyskland kan ikke forbinde)
- BGP routing-hændelser
- CDN-fejlkonfiguration i bestemte PoPs
Checks fra 3+ geografiske lokationer skelner mellem "sitet er nede" og "der er et regionalt netværksproblem."
Vigtige metrics at følge
| Metric | Hvad den måler |
|---|---|
| Availability % | Uptime over en rullende periode (dag, uge, måned) |
| TTFB (Time to First Byte) | Hvor hurtigt serveren begynder at svare |
| Response time | Samlet tid til at modtage det fulde svar |
| Incident count | Antal nedbrud i en periode |
| MTTR (Mean Time to Repair) | Gennemsnitlig tid fra opdagelse til løsning |
| MTTD (Mean Time to Detect) | Gennemsnitlig tid fra nedbrudets start til alert fyres |
MTTD er den metric, som uptime monitoring direkte kontrollerer. Et check-interval på 1 minut giver en maksimal MTTD på 1 minut.
Fornuftige alert-grænser
Dårlig alerting er næsten værre end ingen alerting — alert fatigue får teams til at ignorere notifikationer, herunder rigtige hændelser.
Undgå alerts på enkeltstående fejl
Et enkelt fejlet check kan være en forbigående netværksfejl, ikke et rigtigt nedbrud. Hvis man kræver 2 eller 3 på hinanden følgende fejl, før en alert fyres, reduceres false positives dramatisk uden nævneværdig forsinkelse af opdagelsen af reelle hændelser.
Sæt en response time-grænse
Et site, der er 10 sekunder om at svare, er funktionelt ubrugeligt for de fleste brugere, men udløser ikke en standard uptime-alert. Sæt en sekundær alert for, hvornår response time overstiger en grænse (f.eks. 3 sekunder).
Brug eskaleringstrin
- 1 fejlet check: log stille
- 2 på hinanden følgende fejl: email-alert
- 5+ på hinanden følgende fejl (eller 10+ min downtime): ring til vagtholdet (SMS/PagerDuty)
Hvad du bør monitorere
Overvåg ikke kun din forside. Overvej også:
- Kritiske brugerrejser: login-side, checkout, API health endpoint
- Subdomæner:
api.,mail.,app.kan gå ned uafhængigt af hinanden - Tredjepartsafhængigheder: hvis din app kalder et eksternt API, påvirker dets tilgængelighed dine brugere
- SSL-certifikatudløb: et certifikat, der udløber uden varsel, tager hele sitet offline
Forståelse af uptime SLAs
| Uptime % | Downtime per år | Downtime per måned |
|---|---|---|
| 99% | 3,65 dage | 7,3 timer |
| 99,9% | 8,76 timer | 43,8 minutter |
| 99,95% | 4,38 timer | 21,9 minutter |
| 99,99% | 52,6 minutter | 4,4 minutter |
| 99,999% | 5,26 minutter | 26,3 sekunder |
De fleste shared hosting-udbydere tilbyder 99,9%. Administrerede cloud-platforme (Vercel, Netlify, Cloudflare Pages) opnår typisk 99,99%+ på CDN-laget, mens origin-serverens tilgængelighed er det mest almindelige svage punkt.
Status pages
En offentlig status page tjener to formål: den giver brugerne et sted at tjekke, når noget virker galt, og den demonstrerer gennemsigtighed og operationel modenhed.
Best practices:
- Hav den på et separat domæne eller CDN fra dit hovedsite (en status page, der hostes på den samme server som den app, du overvåger, går ned, når appen går ned)
- Vis historiske hændelsesdata, ikke kun aktuel status
- Opdater den i realtid, efterhånden som hændelser udvikler sig — en status page, der siger "undersøger" i 4 timer, er ikke nyttig
Kom i gang med Sitecheck uptime monitoring
Sitecheck inkluderer uptime monitoring på alle planer:
- Free: 1 monitor med alerts
- Basic: op til 3 monitors
- Pro: op til 5 monitors
Hver monitor tjekker din URL med faste intervaller, registrerer response time og statushistorik og sender en email-alert, så snart en fejl opdages. Ingen infrastruktur at vedligeholde.
Tilføj din første monitor i Uptime-dashboardet — det tager under et minut at sætte op.
Opsummering
Uptime monitoring er et grundkrav for ethvert live website. Prisen for ikke at have det — oversete nedbrud, frustrerede kunder, SEO-skade og langsom hændelsesreaktion — overstiger langt den indsats, det kræver at sætte det op. Start med din mest kritiske URL, bekræft at alerts når de rigtige personer, og udvid derefter dækningen til hele din stack.
At opdage problemer inden for minutter i stedet for timer er forskellen mellem en mindre hændelse og en krise.