Oppetidsovervågning: opdag fejl på websites og kritiske flows

Forsiden kan svare, mens købet fejler

Et website kan være tilgængeligt, selv om login ikke virker, søgningen returnerer en fejl, eller en ordre aldrig bliver bekræftet. Derfor begynder køb af overvågning med en beslutning om, hvad »virker« betyder. Et enkelt HTTP-check og et gennemført brugerforløb undersøger forskellige ting.

Guiden er til webansvarlige, udviklingsteams og driftsansvarlige, der vil opdage fejl før eller samtidig med kunderne. Vi sammenligner ekstern overvågning af websites, API'er og kritiske brugerforløb. Det er et andet køb end en statusside til kundekommunikation eller fuld intern analyse af servere og applikationskode.

Kort fortalt

Better Stack: Undersøg det, når overvågning skal hænge sammen med vagtplaner, eskalering og håndtering af hændelser.
Checkly: Undersøg det, når udviklerne vil vedligeholde browser- og API-checks som kode sammen med produktet.
Pingdom: Undersøg det, når kunstige testforløb skal suppleres med måling af rigtige besøgendes oplevelse.
UptimeRobot: Undersøg det, når I først har brug for tydelig overvågning af endpoints, svartid, certifikater og planlagte job.

Hvilket lag skal I overvåge?

Et oppetidscheck spørger eksempelvis, om en URL svarer korrekt. Et syntetisk browsercheck udfører et planlagt forløb som login og søgning i en rigtig browser. Real User Monitoring, ofte forkortet RUM, måler den oplevelse, faktiske besøgende har. Et heartbeat er et signal fra et job, som skal komme med en aftalt rytme.

De fire former supplerer hinanden. Manglende trafik kan give få RUM-observationer, selv om systemet er i stykker. En grøn forside kan overse en ødelagt bestilling. Og et heartbeat efter et job beviser kun det, som koden bag signalet faktisk har kontrolleret.

Sammenligning

Stryg tabellen til siden for at se alle kolonner.

Tjeneste	Dokumenteret styrke at undersøge	Pakke-/forbrugsgrænse	Hvem skal eje opsætningen?
Better Stack	Checks samlet med vagtplan og eskalering	Responder-licenser, ekstra monitors og Playwright-minutter afregnes særskilt	Drift og den ansvarlige vagtorganisation
Checkly	API- og Playwright-checks som kode	Browser-/API-kørsler og almindelige monitors har forskellige rammer	Et team, som kan vedligeholde tests
Pingdom	Syntetisk overvågning og RUM	Syntetisk kapacitet vælges separat fra RUM-sidevisninger	Web- eller driftsteam med ansvar for målinger
UptimeRobot	Endpoint-, certifikat- og jobovervågning	Solo har 60 sekunders interval, Team 30 og Scale 15	Den ansvarlige for de overvågede tjenester

Tabellen er en redaktionel sammenligning af arbejdsformer. Intervaller og kapaciteter er leverandøroplysninger; de dokumenterer ikke, hvor hurtigt jeres organisation faktisk får løst en fejl.

Better Stack: fra fejl til den rette person

Better Stack beskriver HTTP- og netværkschecks, heartbeats og Playwright-baserede transaktionschecks. Samtidig beskrives vagtplaner, eskalering og samling af hændelser. Det er relevant, hvis problemet ikke kun er at opdage fejlen, men også at få den placeret hos en person med ansvar for at reagere. Overvågning og hændelser

Prissiden skelner mellem gratis teammedlemmer til Telemetry og betalte responders med adgang til Uptime og hændelseshåndtering. Den angiver 10 inkluderede monitors og særskilt betaling for ekstra monitors. Playwright-transaktioner prissættes efter minutter, og heartbeats har egne udvidelser. »Én platform« betyder dermed ikke én ubegrænset kapacitet. Prisstruktur

Vores vurdering: Vælg Better Stack til afprøvning, når ansvar, vagt og alarmer skal bindes sammen. Sammenlign med Checkly, hvis tests som kode er det vigtigste udgangspunkt. Lad en testhændelse gå til den første ansvarlige, undlad at kvittere, og kontrollér den aftalte eskalering. Afslut med at sikre, at en normalisering lukker eller opdaterer hændelsen på den ønskede måde.

Checkly: vedligehold checks som produktkode

Checkly beskriver overvågning som JavaScript/TypeScript, Terraform eller Pulumi og browserforløb med Playwright. Det gør løsningen relevant, når udviklerne allerede arbejder med automatiserede tests og vil behandle overvågning som noget, der versionsstyres og ændres sammen med produktet. Det kræver samtidig et tydeligt ejerskab af testkoden. Produkt og kodeeksempler

Planerne skelner mellem almindelige monitors og browser-/API-kørsler. Team beskriver adgang til private locations; de gør det muligt at køre checks fra egen infrastruktur. En særlig afregningsdetalje gælder Playwright Check Suites: hver påbegyndt blok på 30 sekunder tæller som en kørsel, så en suite på 45 sekunder bruger to. Almindelige browserchecks og suites må derfor ikke budgetteres som identiske enheder. Planer og definitioner

Vores vurdering: Vælg Checkly til afprøvning, hvis et udviklingsteam vil eje overvågningen i kode. Sammenlign med UptimeRobot, hvis enkle endpointchecks er tilstrækkelige. Lav en ufarlig ændring i testmiljøets brugerflade og se, om testen fejler af den rigtige grund. Aftal, hvem der retter monitoren, når produktet ændrer sig, så gamle testforventninger ikke bliver til konstante falske alarmer.

Pingdom: sammenhold testforløb med brugeroplevelsen

Pingdom beskriver både syntetisk overvågning og Real User Monitoring. Den syntetiske del omfatter oppetid, sidehastighed og transaktioner, mens RUM viser oplevelsen hos faktiske besøgende opdelt efter blandt andet browser, enhed og geografi. Kombinationen er relevant, hvis et hurtigt testcheck ikke forklarer, hvorfor nogle kundetyper oplever et langsomt website. Produkt

Abonnementet sammensættes separat for syntetisk overvågning og RUM. Prissidens kapacitetsvalg angiver antal uptimechecks, advanced checks og SMS for den første del, mens RUM vælges efter sidevisninger. Et stort publikum ændrer derfor især RUM-grundlaget, mens flere testforløb påvirker en anden del af regningen. En konkret slutpris er ikke fastslået i vores kildeudtræk. Abonnementsberegner

Vores vurdering: Vælg Pingdom til afprøvning, når I vil undersøge både tilgængelighed og reel brugeroplevelse. Sammenlign med Checkly, hvis kodebaserede tests er det vigtigste. Brug en testside og et aftalt målegrundlag til at se, om I kan skelne en generel forsinkelse fra et problem, der især rammer en bestemt browser eller region. RUM kræver desuden en beslutning om den konkrete dataindsamling på sitet.

UptimeRobot: målrettet kontrol af tjenester

UptimeRobot beskriver HTTP-, keyword-, port-, DNS- og jobovervågning. Det er relevant, hvis I vil opdage, at et endpoint er nede, et bestemt svar mangler, eller et tilbagevendende job ikke har meldt tilbage. Vælg det check, der svarer til fejlen; en åben port er ikke i sig selv en gennemført kundetransaktion. Checktyper

Den aktuelle planoversigt viser 60 sekunders interval på Solo, 30 sekunder på Team og 15 sekunder på Scale. Gratisplanen beskrives til hobby- og nonprofitprojekter med fem minutters interval. SMS- og opkaldskreditter er en separat begrænsning og fornyes ifølge siden ikke automatisk som en almindelig månedlig pulje; yderligere kreditter kan købes. Planer og alarmforbrug

Vores vurdering: Vælg UptimeRobot til afprøvning, når behovet kan udtrykkes som konkrete endpoint- og jobchecks. Sammenlign med Better Stack, hvis bemandet vagt og eskalering er den store udfordring. Prøv både et forkert HTTP-svar og et job, som slet ikke kører. Kontrollér, at begge fejl kommer frem til den ansvarlige med en forståelig forklaring.

Beregn kørsler, ikke kun antal tests

Et forløb, der kører hvert femte minut døgnet rundt i 30 dage, udføres 8.640 gange: 12 gange i timen × 24 timer × 30 dage. Hvis det udføres selvstændigt fra tre lokationer ved hvert interval, bliver det 25.920 udførelser før retries. Det er et regneeksempel, ikke en påstand om standardopsætningen hos en bestemt leverandør.

Round-robin, hvor lokationer skiftes til at køre, er noget andet end parallel kørsel fra alle lokationer. Checkly beskriver denne forskel i sin pris-FAQ. Hos Better Stack skal browserforbruget desuden oversættes til Playwright-minutter; hos Pingdom og UptimeRobot er de relevante pakke- og alarmgrænser andre. Checkly · Better Stack

Lav en liste over kritiske flows, interval, lokationer, forventet varighed og hvem der skal modtage alarmer. Bed derefter om beregningen for normal drift og for en måned med mange fejl og genforsøg. Hyppigere målinger kan være nyttige, men de skal passe til den reaktion, I faktisk kan levere.

Test alarmkæden med en ufarlig fejl

Brug et testmiljø eller et særskilt testendpoint. Fremkald en aftalt fejl, og notér tidspunktet. Kontrollér, hvornår den bliver opdaget, hvem der får besked, hvordan der kvitteres, og hvad der sker, hvis første person ikke reagerer. Genopret derefter normal tilstand og kontrollér afslutningen.

For et browserflow skal I også afprøve en situation, hvor siden svarer, men det forventede resultat mangler. Brug testkonti og testdata, og vælg et forløb, der ikke skaber rigtige ordrer eller betalinger. En monitor kan ellers være teknisk korrekt og samtidig skabe arbejde i driftssystemerne.

En god alarm fortæller, hvilken tjeneste der er påvirket, hvad der fejlede, og hvor modtageren skal begynde. For mange upræcise alarmer gør det sværere at reagere på den vigtige. Vurdér derfor støj og anvendelighed sammen med måleintervallet.

Aftal ejerskab og forbindelse til kundekommunikation

Giv hver monitor en ansvarlig og en kort instruktion til fejlsøgning. Planlagte ændringer skal håndteres med vedligeholdelsesvinduer eller anden aftalt dæmpning, så teamet stadig kan stole på signalerne. Gennemgå monitors, når et system lukkes eller et brugerflow ændres.

Beslut særskilt, hvornår en teknisk alarm skal blive til en kundevendt statusmeddelelse. En enkelt fejl i en syntetisk test er ikke nødvendigvis en driftsforstyrrelse for alle kunder. Omvendt kan et kritisk flow kræve kommunikation, selv om forsiden stadig er grøn.

Metode og kilder

Udvalget belyser forskellige relevante arbejdsgange og er ikke en komplet markedsoversigt. Leverandørerne står alfabetisk. Produktfakta kommer fra leverandørernes egne sider; anbefalinger, eksempler og forslag til afprøvning er redaktionelle vurderinger. Vi har ikke udført produkttest eller indhentet tilbud. Dansk support og aftalevilkår for jeres konkrete installation er ikke verificeret.

Kilder kontrolleret 20. september 2026. Publicerings- og ændringsdato er ikke entydigt oplyst for alle kilder; kontroldatoen er vores læsedato. Planer og priser kan ændre sig. Kommercielle relationer mellem Branchekompas/Carter & Co og leverandørerne er uafklarede; vi fremsætter ingen erklæring om dokumenteret økonomisk uafhængighed.

Relaterede guider

Se statussider til driftsinformation for kommunikation om hændelser og feature flags for kontrolleret aktivering af produktændringer.