Gå til innhold

Varslingslogg

Varslingsloggen er den autoritative historikken over alle varslinger ePortal har forsøkt å sende — både planlagte og hendelsesutløste. Hver rad viser når varslet ble forsøkt sendt, hvilken mal og plan som ble brukt, hvem mottakeren var, hvilken status leveransen fikk, og hvis det feilet: hvorfor. Logginnstillingene styrer hva som lagres, hvor lenge, og hvem som har innsyn.

Tilgang

Hvem Hva trengs
Rolle som kan endre Administrator
Modul som kreves Portalinnstillinger (Settings) — moduleID 99
Effekt på hvem Alle som genererer eller mottar varslinger i tenanten

Logg-lesing kan delegeres til konsulent-rolle for feilsøking uten å gi full innstilling-redigering. Selve loggvisningen krever ikke admin-rolle for å åpne — men endring av oppbevaringspolicy og filterregler gjør.

Innstillinger

Innstilling Betydning Standard Konsekvens Tilgang
Oppbevaring Antall dager loggrader beholdes før automatisk sletting 90 dager Eldre rader slettes irreversibelt av nattlig oppryddingsjobb Administrator
Logg-nivå Hvilke utfall som logges (alle / kun feilet / kun kritiske) Alle Påvirker mengden loggdata og innsynsverdi ved feilsøking Administrator
Lagre meldingsinnhold Om hele tekstkroppen lagres med hver rad På Når av: kun metadata; mister mulighet for å vise eksakt sendt tekst Administrator
PII-anonymisering Om mottaker-e-post/telefonnummer maskeres i loggvisning Av Når på: vises som j***@example.com for å overholde GDPR-policy Administrator
Eksport tillatt Om administrator kan eksportere logg til CSV/Excel På Når av: kun visning i UI Administrator
Webhook ved feil Sender HTTP POST til ekstern endepunkt ved varsel-feil Av Brukes for å trigge varsling i tredjepart-overvåkning Administrator

Detaljert beskrivelse per innstilling

Oppbevaring

Betydning. Hvor mange dager loggrader beholdes i databasen. Eldre rader slettes av en nattlig oppryddingsjobb. Påvirker både databasestørrelse og hvor langt tilbake du kan feilsøke.

Gyldige verdier. Heltall 7–730 dager.

Standardverdi. 90 dager — gir nok historikk for kvartalsrapport og typisk feilsøking.

Når trer endringen i kraft. Den nattlige oppryddingsjobben bruker ny verdi neste kjøring. Reduksjon fra 90 til 30 dager sletter rader umiddelbart i neste nattlige kjøring — ikke når lagring skjer.

Påvirker historiske data. Ja. Reduksjon sletter eksisterende rader som faller utenfor ny grense. Sletting er irreversibel.

Konsekvens for andre moduler.

  • GDPR-policy — kortere oppbevaring reduserer eksponering av personopplysninger.
  • Feilsøking — for kort oppbevaring gjør det vanskelig å spore tilbakemeldinger fra mottakere som klager dager senere.
  • Rapportering — månedsrapporter må kjøres innen oppbevaringsperioden.

Avhengigheter. Nattlig oppryddingsjobb må kjøre — sjekk driftsstatus hvis logg vokser uten begrensning.

Hvem kan endre. Administrator.

Logg-nivå

Betydning. Styrer hvilke utfall som lagres i loggen. Reduserer database-volum hvis du kun trenger feiltilstander, men begrenser samtidig hva som er sporbart.

Gyldige verdier.

  • Alle — alle utsendinger lagres uansett status.
  • Kun feilet — kun rader med status feilet eller avvist.
  • Kun kritiske — kun systemfeil (mal mangler, gateway nede); individuelle bouncer logges ikke.

Standardverdi. Alle.

Når trer endringen i kraft. Umiddelbart for nye utsendinger.

Påvirker historiske data. Nei. Allerede lagrede rader påvirkes ikke.

Konsekvens for andre moduler.

  • Feilsøking — "Kun feilet" gjør det umulig å bekrefte at en suksess-utsending faktisk skjedde.
  • Rapportering — utsendingsvolum og åpningsstatistikk krever full logging.
  • GDPR — mindre logging = mindre PII lagret.

Avhengigheter. Ingen.

Hvem kan endre. Administrator.

Lagre meldingsinnhold

Betydning. Styrer om hele emne + kropp lagres med hver loggrad, eller om kun metadata (tidspunkt, mottaker, mal-ID, status) lagres.

Gyldige verdier. Av eller på.

Standardverdi. På.

Når trer endringen i kraft. Umiddelbart for nye utsendinger.

Påvirker historiske data. Nei. Tidligere lagret innhold beholdes til oppbevaringsperioden utløper.

Konsekvens for andre moduler.

  • Feilsøking — uten innhold kan du ikke verifisere hva mottaker faktisk fikk.
  • GDPR — meldingsinnhold er ofte PII; å ikke lagre er en personvernsfordel.
  • Database-størrelse — meldingsinnhold er den største faktoren for log-størrelse.

Avhengigheter. Ingen.

Hvem kan endre. Administrator.

PII-anonymisering

Betydning. Når på maskerer loggvisning mottaker-e-postadresser, mobilnumre og personnavn slik at en administrator kan feilsøke uten å eksponere personopplysninger unødig.

Gyldige verdier. Av eller på.

Standardverdi. Av.

Når trer endringen i kraft. Umiddelbart i UI. Underliggende lagrede data endres ikke — anonymisering skjer kun ved visning.

Påvirker historiske data. Visningsmessig ja, lagringsmessig nei. Eksport overstyrer ikke maskering med mindre Eksport tillatt brukes med eksplisitt PII-flagg.

Konsekvens for andre moduler.

  • Feilsøking — gjør det vanskeligere å bekrefte at riktig mottaker fikk varslet.
  • GDPR-revisjon — anbefales på i produksjonsmiljøer.

Avhengigheter. Ingen.

Hvem kan endre. Administrator.

Eksport tillatt

Betydning. Styrer om administrator kan eksportere loggdata til CSV eller Excel for ekstern analyse.

Gyldige verdier. Av eller på.

Standardverdi. På.

Når trer endringen i kraft. Umiddelbart.

Påvirker historiske data. Nei.

Konsekvens for andre moduler.

  • Datasikkerhet — eksport til lokal disk omgår tenantens tilgangskontroll. Vurder å sette av i sensitive miljøer.
  • Rapportering — uten eksport må alle rapporter genereres innenfor ePortal.

Avhengigheter. Ingen.

Hvem kan endre. Administrator.

Webhook ved feil

Betydning. Når på sender ePortal en HTTP POST til konfigurert URL hver gang en varslingskjøring feiler. Brukes for integrasjon med eksterne overvåknings- eller incident-systemer.

Gyldige verdier. Av, eller på med konfigurert URL + valgfri autentisering (Basic/Bearer-token).

Standardverdi. Av.

Når trer endringen i kraft. Umiddelbart for nye feil.

Påvirker historiske data. Nei.

Konsekvens for andre moduler. Webhook-mottaker må tåle volumet — feilstorm kan oversvømme et incident-system. Implementer egen aggregering ved behov.

Avhengigheter. Krever at endepunktet svarer innen 10 sekunder; ellers logges webhook som feilet (men varslingsfeilen er fortsatt registrert i loggen).

Hvem kan endre. Administrator.

Slik bruker du loggen

  1. Åpne Innstillinger → Portalinnstillinger → Planlagte varslinger → Logg (/settings/portal-setting/scheduled-notifications?tab=logs).
  2. Filtrer på Status, Dato, Mal eller Mottaker.
  3. Klikk på en rad for å se detaljer — kanal, tidspunkt, brukt mal, plassholderverdier ved utsending, og status fra leverandør.
  4. Ved feilet utsending: les Feilårsak-feltet for spesifikk gateway-melding.
  5. Klikk Send på nytt for å re-trigge én enkelt utsending hvis feilårsaken er midlertidig (f.eks. SMTP-timeout).

Vanlige problemer

Logg-rader mangler for dager jeg vet at det ble sendt varslinger

Sjekk Logg-nivå — hvis satt til "Kun feilet" lagres ikke suksesser. Sjekk også Oppbevaring — rader eldre enn grensen er slettet.

Status er "sendt" men mottaker har ikke fått e-posten

"Sendt" betyr at e-postleverandøren har akseptert meldingen. Sjekk mottakerens spamfilter, og se etter bounced- eller avvist-rader senere på dagen (leverandører rapporterer bounce asynkront).

Loggen vokser veldig fort

Reduser Oppbevaring, slå av Lagre meldingsinnhold, eller sett Logg-nivå til "Kun feilet". Sjekk også om en plan kjører for ofte (se varslingsplaner — cron-uttrykk under 5 minutter).

Jeg ser maskerte e-postadresser i loggen

PII-anonymisering er på. Slå av midlertidig under feilsøking, eller bruk eksport med PII-flagg hvis tillatt.

Send-på-nytt-knappen er deaktivert

Send-på-nytt er ikke tilgjengelig for status avvist (mottaker eksisterer ikke / blokkert) — kun for midlertidige feil. Send-på-nytt er heller ikke mulig for utsendinger eldre enn 7 dager.

Webhook-en min mottar ingen feil

Sjekk: (1) webhook-URL er korrekt, (2) endepunktet svarer 2xx innen 10 sekunder, (3) det faktisk skjer feilkjøringer i perioden. Sjekk også webhook-status i logg-detaljvisningen for hver feilet rad.

Konsekvensanalyse før endring

Før du endrer logginnstillingene, vurder:

  • [ ] Reduserer du oppbevaring? Sletting er irreversibel — eksporter eldre rader først hvis nødvendig.
  • [ ] Slår du av meldingsinnhold-lagring? Feilsøking blir vanskeligere; vurder personvern-gevinst mot driftsfordel.
  • [ ] Slår du på PII-anonymisering i produksjon? Anbefalt; sørg for at konsulenter med leseinnsyn er informert om visningen endres.
  • [ ] Slår du av eksport? Sjekk at ingen eksisterende rapport-prosess er avhengig av eksport-knappen.
  • [ ] Endrer du logg-nivået midt under en incident? Vent til etterpå — du mister kontekst.
  • [ ] Aktiverer du webhook? Test mot ikke-produksjons-endepunkt først for å unngå feilstorm.

Relaterte sider