Stabil drift

Logning og overvågning: opdag fejl før brugerne gør

En app er ikke stabil, bare fordi forsiden kan åbnes. Login kan fejle, en webhook kan gå i stå, eller data kan blive gemt forkert uden et tydeligt nedbrud. Her får I en enkel model til at se, om appen virker, forstå fejl og reagere uden at fylde logs med adgangskoder eller unødige personoplysninger.

Overvågning skal svare på tre forskellige spørgsmål

Kan appen nås?

Et uptime check kalder en offentlig side eller et endpoint med faste mellemrum. Det opdager utilgængelighed, langsomme svar og i nogle værktøjer certifikatproblemer.

Virker den som forventet?

Metrics viser udviklingen i eksempelvis fejlrate, svartid, kølængde og afsluttede jobs. En grøn forside siger ikke, om fakturaen faktisk blev oprettet.

Hvorfor fejlede det?

Strukturerede logs og eventuelt traces forbinder hændelsen med miljø, version og request, så fejlen kan findes uden at gætte ud fra et screenshot.

Brug den enkleste kombination, der passer til appen. En lille webapp kan ofte begynde med hostingplatformens logs, et eksternt uptime check og få alarmer. En app med flere services, køer og integrationer kan have brug for fælles request-id'er, metrics og distribuerede traces.

Kortlæg det, brugeren faktisk skal kunne

Overvågning bør tage udgangspunkt i appens kritiske handlinger, ikke i en lang liste over tekniske grafer. Skriv de få forløb ned, hvor en fejl stopper arbejdet eller kan skade data og økonomi.

Kritisk handling	Tegn på succes	Tegn på fejl	Ansvarlig
Bruger logger ind	Session oprettes	Mange afvisninger eller timeout	Appansvarlig
Ordre eller sag gemmes	Databasekvittering og id	Fejl, dublet eller manglende id	Systemejer
Integration kører	Godkendt svar eller behandlet event	Kø vokser, retries stopper eller job er stille	Integrationsejer
Mail eller dokument sendes	Leverandøren accepterer opgaven	Afvisning eller permanent fejl	Forretningsejer

En teknisk succes er ikke altid en forretningsmæssig succes. Et endpoint kan svare 200, selv om det efterfølgende job aldrig bliver kørt. Overvåg derfor både kaldet og det resultat, virksomheden er afhængig af.

Skriv logs, der kan bruges under pres

OWASP anbefaler, at en loghændelse giver svar på hvornår, hvor, hvem og hvad. I praksis bør de vigtigste hændelser have et stabilt eventnavn, tidspunkt, miljø, release, resultat og et request- eller interaction-id. Brug maskinlæsbare felter frem for én lang sætning, så logs kan filtreres og tælles.

{
  "timestamp": "2026-08-03T05:42:18.312Z",
  "level": "error",
  "event": "invoice.create.failed",
  "environment": "production",
  "release": "a1b2c3d",
  "requestId": "req_7f91c2",
  "accountId": "acct_42",
  "durationMs": 842,
  "errorCode": "ACCOUNTING_API_TIMEOUT"
}

Eventnavn: Beskriver en stabil handling som invoice.create.failed – ikke en skiftende fejltekst.
Miljø og release: Viser om fejlen rammer produktion, og hvilken version der var aktiv.
Request-id: Gør det muligt at følge samme handling gennem frontend, backend og integrationer.
Fejlkode: Kan bruges i alarmer og support uden at vise en intern stack trace til brugeren.
Varighed og resultat: Gør langsom drift og delvise fejl synlige, også når requesten teknisk gennemføres.

Logs er også data, der skal beskyttes

Logs kan indeholde personoplysninger og afsløre brugsmønstre, interne systemer og forretningsdata. Datatilsynet beskriver logning som en mulig sikkerhedsforanstaltning, men behovet og udformningen skal bero på den konkrete risiko. Adgang, opbevaring og sletning skal derfor være bevidste valg.

Skriv normalt ikke

Adgangskoder, API-nøgler, tokens eller connection strings
Hele request bodies, formularer eller dokumenter
Betalingskort, helbredsdata eller andre følsomme oplysninger
Session-id'er eller reset-links, der kan bruges som adgang
Stack traces og interne detaljer direkte i brugerens svar

Skriv hellere

Interne id'er eller pseudonyme referencer, når identitet er nødvendig
Faste event- og fejlkoder uden råt indhold
Resultat, varighed, miljø, release og request-id
Administrative ændringer og adgangshændelser efter risikovurdering
Kun de felter, der bruges til drift, sikkerhed eller dokumentation

Begræns hvem der kan læse og slette logs, beskyt dem mod manipulation, og fastlæg en opbevaringsperiode ud fra formål, risiko og eventuelle krav. “Gem alt for en sikkerheds skyld” er ikke en driftsplan.

Sæt checks på det rigtige lag

Offentlig tilgængelighed: Kald appens URL og et sikkert backend-endpoint udefra. Et internt dashboard kan være grønt, mens DNS, certifikat eller routing fejler for brugerne.
Health endpoint: Returnér en enkel status uden versionsnumre, credentials eller interne forbindelsesdetaljer. Aftal om checket kun viser, at processen lever, eller også kontrollerer nødvendige afhængigheder.
Kritisk brugerforløb: Test login, søgning eller lagring i et sikkert testmiljø eller med en kontrolleret testkonto. Undgå monitors, der opretter rigtige betalinger, mails eller kundedata i produktion.
Baggrundsjob og webhooks: Registrér seneste vellykkede kørsel og alarmér ved usædvanlig stilhed. Et job, der aldrig starter, producerer ikke nødvendigvis en fejl at søge efter.

Lav få alarmer med en tydelig modtager

En alarm er kun nyttig, hvis nogen kan forstå og handle på den. Begynd med hændelser, der kræver reaktion: appen er utilgængelig, fejlprocenten stiger markant, et kritisk job er udeblevet, eller en vigtig integration afviser kald.

Navngiv ejer og reserve: En fælles indbakke uden ansvar giver falsk tryghed.
Skriv konsekvensen: Forklar hvilken brugerhandling eller proces der kan være ramt.
Link til undersøgelsen: Alarmen bør pege på relevant dashboard, søgning og runbook.
Dæmp støj: Brug vedvarende fejl, flere målesteder eller passende tidsvinduer, hvor værktøjet understøtter det.
Test leveringen: Udløs en kontrolleret alarm og bekræft, at den rigtige person modtager og forstår den.
Send også raskmelding: Det skal være tydeligt, hvornår hændelsen ikke længere er aktiv.

Brug platformens muligheder uden at låse planen til én stack

Vælg efter den hosting og arkitektur, appen allerede bruger. En leverandørs dashboard kan være et godt udgangspunkt, men kontrollér logtyper, adgang, opbevaringsperiode, alarmer og eksport i jeres konkrete abonnement og region.

Miljø	Praktisk start	Kontrollér især
Netlify	Deploy- og function logs samt relevante metrics	Opbevaringsperiode og behov for ekstern alarmering eller log drain
Vercel	Runtime logs og Observability for functions og routes	Opbevaringsperiode, loggrænser og eksport til længere historik
Firebase	Performance Monitoring til weboplevelse og netværkskald	Supplerende backend-, fejl- og sikkerhedslogs efter arkitektur
Azure	Azure Monitor og Application Insights	Sampling, persondata, action groups og reelle modtagere
Flere services	Fælles felter og eventuelt OpenTelemetry	Request-korrelation, dataejerskab, omkostning og adgang

En kort runbook giver ro, når alarmen kommer

Bekræft påvirkningen: Hvilket miljø, brugerforløb og tidsrum er ramt?
Find ændringen: Sammenhold første fejl med seneste deploy, konfiguration og eksterne hændelser.
Følg request-id og eventkode: Find samme handling på tværs af de relevante komponenter.
Begræns skaden: Stop et job, slå en integration fra eller rul tilbage, hvis det er den sikreste dokumenterede handling.
Beskyt data: Undersøg dubletter, manglende behandling og behov for gendannelse, før køer eller retries startes igen.
Bekræft rettelsen: Kør det kritiske forløb og kontrollér både resultat, metrics og logs.
Dokumentér bagefter: Notér årsag, konsekvens, tidslinje og den kontrol, der skal forhindre en gentagelse.

Typiske fejl

Kun forsiden overvåges: Appen svarer, mens login, database eller integrationer er brudt.
Alt skrives med console.log: Hændelser mangler faste felter, niveau og sammenhæng og kan ikke filtreres pålideligt.
Hele requests logges: Tokens, formularer og persondata kopieres ind i et nyt system med bred adgang.
Alarm på enhver enkelt fejl: Modtagerne vænner sig til støj og overser den hændelse, der betyder noget.
Ingen ser efter stille jobs: En planlagt opgave stopper uden at kaste fejl, og problemet opdages først i regnskabet.
Logs findes kun hos én leverandør: Ingen har afklaret adgang, opbevaringsperiode eller hvad der sker, når et projekt eller abonnement ændres.
Runbooken er uprøvet: Under nedbrud ved ingen, hvem der må rulle tilbage, eller hvordan data kontrolleres bagefter.

Tjekliste før appen bruges i hverdagen

☐ De vigtigste brugerhandlinger og deres tegn på succes er skrevet ned.
☐ Offentlig tilgængelighed kontrolleres udefra – ikke kun i hostingens eget dashboard.
☐ Kritiske jobs og integrationer registrerer seneste vellykkede behandling.
☐ Fejllogs har eventnavn, miljø, release, request-id og en stabil fejlkode.
☐ Secrets, tokens og unødige personoplysninger er fjernet eller maskeret.
☐ Adgang til logs, opbevaring og sletning er besluttet og dokumenteret.
☐ Få alarmer har en navngiven modtager, konsekvens og link til en runbook.
☐ Alarmlevering og raskmelding er testet med en kontrolleret hændelse.
☐ En nylig deploy kan forbindes med logs og rulles tilbage efter en kendt procedure.
☐ Det kritiske forløb er afprøvet efter rettelse – ikke kun markeret grønt i et dashboard.

Relaterede guides

Backup og gendannelsestest, når data eller drift er ramt API-nøgler og secrets, som aldrig må ende i logs GitHub Actions til automatiske kontroller før deployment Azure Functions med Application Insights Se hele guidebiblioteket

Officielle kilder

Funktioner, begrænsninger og menupunkter kan ændre sig. Kontrollér altid den valgte platforms aktuelle dokumentation og jeres eget abonnement før opsætning i produktion.