Sådan fungerer PingPuffins overvågningssystem

Version: 1.5
Sidst opdateret: 20. februar 2026

Indholdsfortegnelse

Oversigt
Tjek-intervaller og hyppighed
Fejldetektion
Genoprettelse og statusændringer
Manuel opdatering
Forventede HTTP-statuskoder
Beskyttelse mod monitor-fejl
Notifikationssystem
Offentlige status-sider
Automatiske dashboard-opdateringer
Dataindsamling og lagring
Tekniske specifikationer
Privatliv og sikkerhed
Systempålidelighed
Almindelige scenarier og eksempler

Oversigt

PingPuffin overvåger HTTP- og HTTPS-endpoints 24/7 for at sikre, at dine websites er tilgængelige. Vores system er bygget med fokus på pålidelighed, præcision og gennemsigtighed.

Nøglefunktioner

✅ Automatiske tjek hvert 3. minut – alle monitors tjekkes regelmæssigt
✅ 2-tjek verifikation for at undgå falske alarmer
✅ 24/7/365 overvågning uden pauser
✅ Notifikationer via e-mail, Slack, SMS, WhatsApp og webhook (nedetid, genoprettelse, advarsler, SSL-udløb, langsom svartid)
✅ SSL-certifikat-advarer – besked 8 dage og 2 dage før certifikat udløber
✅ Langsom svartid – kan vælge at få alarm, når sitet svarer for langsomt (indstillinger)
✅ Offentlige status-sider – del en status-side med dit eget navn og logo
✅ Øjeblikkelig genoprettelse når dit site er tilbage
✅ Manuel opdatering for hurtig verifikation
✅ Beskyttelse mod interne fejl i monitor-systemet

Hvorfor gennemsigtighed er vigtigt

Vi tror på åbenhed omkring, hvordan vores overvågning fungerer. Dette dokument forklarer præcis, hvordan vi detekterer nedetid, hvordan vi undgår falske alarmer, og hvordan vi sikrer, at du får besked hurtigst muligt, når der er et reelt problem.

Tjek-intervaller og hyppighed

Automatiske tjek

Alle aktive monitors tjekkes automatisk hvert 3. minut. Tjek kører parallelt, så alle dine monitors bliver tjekket hurtigt og jævnt.

Tjek sker i faste intervaller døgnet rundt
Ingen pauser, ingen weekends, ingen helligdage
Du behøver ikke gøre noget – overvågningen kører automatisk

Manuel opdatering

Du kan altid udløse et øjeblikkeligt tjek via "Opdater nu"-knappen i dit dashboard:

Resultat vises med det samme
Bypass af 2-tjek-tærskel for hurtig feedback
Nyttigt efter deployments eller konfigurationsændringer

Dækning

Tilgængelighed: 24/7/365
Parallelle tjek: Alle monitors tjekkes samtidigt
Timeout: Standard 30 sekunder (kan konfigureres)
Maksimale redirects: Op til 5 følgeforspørgsler

Fejldetektion

2-tjek verifikationssystem

For at undgå falske alarmer kræver vi 2 på hinanden følgende fejl, før vi markerer et site som nede.

Hvordan det fungerer

Første Fejl (00:00):

Fejltæller sættes til 1
Status forbliver uændret (f.eks. UP)
Ingen notifikation sendes
System logger fejlen til intern overvågning

Anden Fejl (00:05):

Fejltæller opdateres til 2
Status ændres til DOWN
Incident oprettes automatisk
Notifikation sendes til alle konfigurerede kanaler

Total tid: ~5-10 minutter fra første fejl til DOWN-status.

Hvorfor 2-tjek?

Transiente netværksproblemer (DNS blips, kortvarige timeouts, midlertidige serverfejl) forekommer selv på stabile sites. Ved at kræve 2 fejl:

✅ Eliminerer vi falske alarmer fra kortvarige problemer
✅ Bekræfter vi, at der er et reelt problem
✅ Forbedrer vi brugertilliden til notifikationer

Hvad tæller som en fejl?

Følgende situationer markeres som fejl:

HTTP-fejlkoder

4xx Client Errors: 400, 403, 404, 405, osv. (medmindre eksplicit tilladt)
5xx Server Errors: 500, 502, 503, 504, osv.

Netværksfejl

Timeout: Ingen respons inden for timeout-perioden (standard: 30 sekunder)
Connection Refused: Serveren afviser aktivt forbindelser
DNS Failure: Kan ikke løse domænenavnet
Network Unreachable: Host er ikke tilgængelig på netværket

SSL/TLS-fejl

Invalid Certificate: Certifikatet er ugyldigt
Expired Certificate: Certifikatet er udløbet
Untrusted Certificate: Certifikatet er ikke fra en betroet CA
Hostname Mismatch: Certifikatets hostname matcher ikke URL'en

Langsom svartid

Response time over tærskel: Hvis du har aktiveret notifikation ved langsom svartid (Indstillinger), tæller et check som fejl, når svartiden overstiger din tærskel (5–15 sekunder). Samme 2-tjek-logik gælder: to konsekutive langsomme checks giver status down og notifikation.

Håndtering af forskellige fejltyper

Vigtigt: ALLE fejltyper tæller med i fejltælleren.

Eksempel:

Tjek 1: HTTP 500 → Fejltæller: 1, Status: UP (venter på bekræftelse)
Tjek 2: Timeout  → Fejltæller: 2, Status: DOWN (bekræftet fejl)

Rationale:

Hvis en server skifter mellem forskellige fejltyper, indikerer det ustabilitet
Det er ikke mindre alvorligt, hvis fejltypen ændrer sig
Enhver fejl betyder, at sitet ikke fungerer korrekt

Genoprettelse og statusændringer

Øjeblikkelig genoprettelse

Når dit site kommer tilbage, reagerer vi straks – ingen 2-tjek-tærskel for genoprettelse.

Genoprettelsesflow:

Status: DOWN
Tjek 1: Site svarer med HTTP 200 → Fejltæller nulstilles, Status: UP
Resultat: Øjeblikkelig genoprettelse, notifikation sendt

Hvorfor øjeblikkelig genoprettelse?

✅ Brugere ønsker hurtig feedback, når deres site er tilbage
✅ Ingen grund til at vente på bekræftelse af, at noget virker
✅ Bedste praksis inden for overvågning
✅ Reducerer bekymring og ventetid

Status-tilstande

🟢 UP (Oppe)

Betydning:

Site svarer med en forventet HTTP-statuskode (standard: 2xx og almindelige 3xx)
Svartid er inden for acceptabelt område
Ingen fejl detekteret

Notifikationer:

Sendes ved genoprettelse fra DOWN-status

🔴 DOWN (Nede)

Betydning:

Site fejlede 2+ på hinanden følgende tjek
Incident oprettet og spores
Alle konfigurerede notifikationskanaler alarmeret

Varighed:

Registreres fra første DOWN-tjek til genoprettelse
Vises i incident-log med præcis varighed

🟡 WARNING (Advarsel)

Betydning:

Site svarer, men med advarsler
Eksempler: Langsom svartid, Cloudflare-udfordring detekteret
Overvågning fortsætter normalt

Notifikationer:

Kan konfigureres per bruger

🔵 REDIRECT (Omdirigering)

Betydning:

Permanent redirect (301) detekteret til anden URL
Site er funktionelt, men URL har ændret sig
Du kan vælge at opdatere URL eller fortsætte med at overvåge oprindelig

Notifikationer:

Kan konfigureres per bruger

Cloudflare-beskyttede Sites

Automatisk Håndtering:

PingPuffin håndterer automatisk sites bag Cloudflare. Adfærden afhænger af HTTP-statuskoden:

5xx (fx 503 Service Unavailable): Alle serverfejl (500, 502, 503, 504 osv.) markeres altid som "Down" og giver notifikation og nedetid i grafen – også når svaret indeholder Cloudflare-tekst. Cloudflare sender ofte 503 videre fra din server og wrapper den i sin egen fejlside; vi fortolker 5xx som at selve servicen er utilgængelig.

4xx (fx 403 Forbidden, 429 Too Many Requests): Hvis serveren svarer med 403 eller 429 og vi detekterer Cloudflare (headers eller indhold), markeres monitoreren som "Problematic" (warning) i stedet for "Down". Det betyder typisk Cloudflare bot-protection eller rate limit – vi kan ikke afgøre om dit site reelt er nede, kun at beskyttelsen blokerer vores tjek.

Hvorfor "Problematic" for 4xx med Cloudflare?

Hvis vi får et HTTP-svar (fx 403), er der forbindelse til serveren. Uptime monitoring handler om tilgængelighed – ved 4xx med Cloudflare antager vi at beskyttelsen blokerer tjekket, ikke at selve sitet er nede. Derfor viser vi "Problematic" så du ved at der er en beskyttelse aktiv.

Optional: Konfigurer Cloudflare til bedre Monitoring

Hvis du vil undgå "Problematic" status for dit Cloudflare-beskyttede site, kan du:

WAF-regler: Opret en regel der tillader requests fra PingPuffin's User-Agent:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Browser Integrity Check: Overvej at slå denne fra for monitoring IPs
Rate Limiting: Juster rate limiting så monitoring requests ikke bliver blokeret

PingPuffin's Monitoring IP: 188.245.198.146 (til whitelisting hvis nødvendigt)

Manuel opdatering

Bruger-initierede tjek

Du kan altid udløse et øjeblikkeligt tjek via "Opdater nu"-knappen i dashboardet.

Adfærd:

Bypass af 2-tjek-tærskel: Resultat vises og anvendes med det samme
Øjeblikkelig statusopdatering: Hvis status ændrer sig, opdateres den straks
"Sidst tjekket" opdateres: Dashboardet viser det nye tjektidspunkt med det samme; i oversigten kan du se "Opdateret lige nu" for den monitor du opdaterede
Notifikation: Sendes hvis status ændrer sig
Fejltæller opdateres: Tælleren opdateres baseret på resultat

Anvendelsestilfælde

✅ Hurtig verifikation efter deployment af rettelser
✅ Test af ny monitor-konfiguration
✅ Øjeblikkelig statustjek uden at vente på næste automatiske tjek
✅ Debugging af forbindelsesproblemer

Eksempel:

00:00 - Automatisk tjek fejler → Fejltæller: 1, Status: UP
00:02 - Du klikker "Opdater nu" → Tjek fejler → Status: DOWN øjeblikkeligt
Resultat: Manuel tjek springer 2-tjek-tærskel over for hurtig feedback

Forventede HTTP-statuskoder

En monitor betragtes som UP, når serveren returnerer en HTTP-statuskode, som du har markeret som acceptabel. Som standard behandler PingPuffin disse koder som succes:

Standard accepterede koder

2xx Succes

200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content

3xx Omdirigeringer (efter at redirects er fulgt, vurderes den endelige respons)

301 Moved Permanently
302 Found
303 See Other
304 Not Modified
307 Temporary Redirect
308 Permanent Redirect

Enhver anden statuskode (fx 4xx eller 5xx) behandles som fejl, medmindre du eksplicit tilføjer den til monitorens forventede statuskoder.

Brugerdefinerede forventede statuskoder

Du kan angive, hvilke koder der tæller som succes per monitor. For eksempel:

401 Unauthorized for en login- eller beskyttet side, der korrekt returnerer "auth required"
403 Forbidden hvis den respons er forventet for den URL, du overvåger
404 Not Found kun hvis du bevidst overvåger en "not found"-side

Når du opretter eller redigerer en monitor, kan du angive en komma-separeret liste over forventede koder (fx 200,201,401). Hvis du lader den stå som standard, bruges den fulde liste ovenfor.

Hvor det gælder

Alle HTTP(S) uptime-tjek bruger denne regel (automatiske tjek og manuel "Opdater nu").
Status bestemmes ved at sammenligne den endelige responskode (efter redirects) med din forventede liste.
Se Tekniske specifikationer for timeout, redirect-grænser og andre request-detaljer.

Beskyttelse mod monitor-fejl

Intern vs. ekstern fejl

Det er kritisk at skelne mellem fejl i dit site og fejl i vores monitor-system.

Site-fejl (overvåges)

Disse fejl fra dit site tæller som fejl:

✅ HTTP 500 fra target-sitet → Tæller som fejl
✅ Timeout ved forbindelse til target-site → Tæller som fejl
✅ DNS-fejl for target-domæne → Tæller som fejl

Monitor-system-fejl (beskyttet)

Disse fejl i PingPuffin's kode markerer IKKE dit site som nede:

❌ PHP-exception i PingPuffin-kode → Markerer IKKE site som nede
❌ Database-forbindelsesfejl → Markerer IKKE site som nede
❌ Intern logik-fejl → Markerer IKKE site som nede

Administrator-alarmering

Når monitor-systemet fejler:

Logning:

Kritisk fejl logges med fuld stack trace
Timestamp og monitor-ID registreres
Alle detaljer gemt til debugging

Email-alarm:

Email sendes til systemadministrator
Indeholder fejlbesked, stack trace, og kontekst
Rate-limiteret: Maksimum 1 email per time per unik fejl
Forhindrer email-oversvømmelse under systemproblemer

Database:

Status forbliver uændret (ingen falske downs)
Ingen incident oprettes
Brugere påvirkes ikke

Eksempel:

Monitor checker kører
→ Intern fejl detekteres i monitor-system
→ Fejl logges med fuld kontekst
→ Email sendes til systemadministrator
→ Database opdateres IKKE
→ Din site status forbliver uændret

Notifikationssystem

Hvornår notifikationer sendes

Nedetid (DOWN): Efter 2 på hinanden følgende fejl bekræftet (~5–10 min)
Genoprettelse (UP): Øjeblikkeligt når sitet kommer tilbage fra DOWN
Advarsel og omdirigering: Konfigurerbart per bruger (redirect, warning)
Langsom svartid: Hvis du har aktiveret det i indstillinger – to konsekutive langsomme tjek giver status DOWN og notifikation
SSL-certifikat udløber snart: Du får besked 8 dage før og 2 dage før udløb (samme kanaler som øvrige notifikationer)
Manuel opdatering: Øjeblikkelig notifikation hvis status ændrer sig ved "Opdater nu"

Notifikationskanaler

Du kan slå én eller flere kanaler til under Integrations (Apps). Alle valgte kanaler modtager de samme hændelser (nedetid, genoprettelse, SSL-udløb, langsom svartid m.m.).

E-mail

Direkte e-mail-notifikationer
Indeholder: site-navn, status, fejlbesked, tidspunkt og link til dashboard

Slack

Besked til din konfigurerede kanal eller DM
Formateret med farver (rød = nede, grøn = oppe) og link til monitor

SMS

Kort besked til dit mobilnummer ved nedetid, genoprettelse, SSL-udløb og langsom svartid
Kræver at du har tilføjet og aktiveret SMS under Integrations

Besked til dit WhatsApp-nummer ved nedetid, genoprettelse, SSL-udløb og langsom svartid
Kræver at du har tilføjet og aktiveret WhatsApp under Integrations

Webhook

POST-kald til dit eget endpoint med JSON (status, svartid, fejlbesked m.m.)
Nyttigt til integration med andre systemer

Notifikation snoozing

Du kan midlertidigt slå notifikationer fra (snooze) i 24 timer:

Under Snooze:

✅ Overvågning fortsætter normalt
✅ Status opdateres i dashboardet
❌ Ingen notifikationer sendes til nogen kanal
⏰ Automatisk un-snooze efter 24 timer

Anvendelsestilfælde:

Planlagt vedligeholdelse
Kendt problem under udrulning
Midlertidig nedlukning

Offentlige status-sider

For hver monitor kan du vise en offentlig status-side, som andre kan åbne uden at logge ind. Siden viser det aktuelle status (oppe/nede/advarsel) og historik.

Tilpasning: Du kan sætte et visningsnavn og et logo (URL) for gruppen, så status-siden matcher dit brand. Ændringer gælder både på dashboardet og på den offentlige side.
Sprog: Status-siden kan vises på dansk, engelsk eller spansk (efter brugerens/besøgendes indstilling).
Del linket: Du får et fast link til status-siden, som du kan dele med brugere eller lægge på dit eget site.

Automatiske dashboard-opdateringer

Auto-refresh mekanisme

Dit dashboard opdateres automatisk hver 30. sekund uden at genindlæse siden.

Dashboardet opdateres automatisk hver 30. sekund med de seneste data og udløser ikke nye tjek – du ser altid den seneste status uden at genindlæse siden.

Hvad opdateres?

Dashboard viser altid de seneste data fra sidste automatiske tjek:

🎨 Status-indikator: Farvet badge (grøn/rød/gul/blå)
⏰ Sidst tjekket: Præcist tidspunkt for sidste tjek
⚡ Svartid: Response time i millisekunder
🔢 Fejltæller: Antal på hinanden følgende fejl
📊 Incident-info: Aktive incidents og varighed

Vigtigt: Auto-refresh respekterer 2-tjek-logikken, fordi den kun viser data fra de automatiske tjek – den udløser ikke nye tjek.

Dataindsamling og lagring

Tjek-poster

Hver eneste tjek gemmes i databasen med følgende information:

Unikt ID for tjek
Reference til monitor
Tidsstempel (når tjek blev udført)
HTTP-statuskode eller fejltype
Svartid i millisekunder
Succes/fejl status
Fejlbesked (hvis relevant)
Redirect information (hvis relevant)
SSL-fejl detaljer (hvis relevant)

Anvendelse:

Uptime-procentberegninger
Historiske grafer og rapporter
Fejlanalyse og debugging
Performance-tracking over tid

Incident tracking

Når status ændrer sig til DOWN, oprettes en incident med følgende data:

Unikt ID for incident
Reference til monitor
Start tidspunkt
Slut tidspunkt (når løst)
Total varighed

Funktioner:

Automatisk oprettelse ved DOWN-status
Kontinuerlig varighed-beregning
Automatisk løsning ved genoprettelse
Komplet historik vedligeholdes
Eksporterbar til CSV

Aktivitetslog

Alle væsentlige hændelser logges:

✅ Status-ændringer (UP → DOWN, DOWN → UP, osv.)
✅ Manuelle tjek udført af brugere
✅ Konfigurations-ændringer
✅ URL-opdateringer
✅ Metadata-opdateringer

Funktionalitet:

Eksporterbar til CSV-format
Søgbar og filtrerbar
Viser detaljer for hver hændelse
Tidsstempler på alle entries

Tekniske specifikationer

HTTP request-parametre

Når PingPuffin tjekker dit site, sendes følgende request:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: */*
Connection: close
[Optional: Authorization header for Basic Auth]

Note: Vi bruger en standard Chrome user agent for at undgå at blive blokeret af sites, der filtrerer custom user agents.

Konfiguration:

Timeout: Kan konfigureres per monitor (standard: 30 sekunder)
Follow Redirects: Ja, op til 5 redirects maksimalt
SSL Verification: Aktiveret (validerer certifikater)
Connection Reuse: Deaktiveret (frisk forbindelse ved hvert tjek)

Forventede HTTP-statuskoder

Monitors betragter et tjek som succesfuldt, når respons-status er i den monitors liste over forventede statuskoder. Som standard accepterer vi et bredt sæt 2xx- og 3xx-koder. For den fulde liste og tilpasning, se Forventede HTTP-statuskoder.

Svartidsmåling

Hvad måles:

DNS lookup-tid
Forbindelsestid (TCP handshake)
SSL handshake-tid (hvis HTTPS)
Time to first byte (TTFB)

Hvad måles IKKE:

Body download-tid (vi læser kun headers)
JavaScript-eksekveringstid
Asset-indlæsningstid

Lagring:

Målt i millisekunder
Gemt ved hvert tjek
Bruges til performance-tracking
Vises i dashboardet

Avancerede overvågningsindstillinger

For avancerede brugere tilbyder vi:

HTTP-metode

GET: Standard metode
POST: For endpoints der kræver POST

Request body

Send JSON eller form data med POST-requests
Nyttigt til API-endpoints der kræver specifikke data

Basic authentication

Username og password for beskyttede endpoints
Passwords krypteres med AES-256-CBC
Aldrig gemt i klartekst

Future features

Custom headers
Request params
Advanced authentication (OAuth, Bearer tokens)

Serverinformationer

Offentlig IP-adresse

PingPuffin's monitoring server bruger følgende offentlige IP-adresse til at udføre checks:

IP-adresse: 188.245.198.146

Hvis du har brug for at whiteliste PingPuffin's IP-adresse i din firewall eller server-konfiguration, kan du bruge denne IP-adresse.

Bemærk: IP-adressen kan ændre sig ved server-migrationer eller infrastruktur-opdateringer. Vi anbefaler at bruge User-Agent header til identificering i stedet for IP-baserede regler, hvis muligt.

User-Agent identificering:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Privatliv og sikkerhed

Datakryptering

Følsomme credentials:

Alle passwords (Basic Auth) krypteres ved lagring
Algoritme: AES-256-CBC (industry standard)
Nøgle: Gemt sikkert i environment variables
IV: Unik initialization vector per kryptering
Decryption sker kun i hukommelsen under tjek
Aldrig eksponeret i logs eller API responses

Dataadgang

Adgangskontrol:

Tjek-resultater kun synlige for monitor-ejeren
Ingen data deles med tredjeparter
Aktivitetslog kun eksporterbar af ejeren
Sikre API-endpoints med authentication

Database-sikkerhed:

Prepared statements (forhindrer SQL injection)
Session-baseret authentication
CSRF-beskyttelse på alle formularer

HTTPS enforcement

SSL/TLS:

Alle monitor-tjek understøtter HTTPS
SSL-certifikat-validering aktiveret
Advarer ved certifikatproblemer
Detekterer udløbne certifikater

Dashboard:

Altid tilgået via HTTPS
Secure cookies (HttpOnly, Secure flags)
HSTS headers anbefalet

Systempålidelighed

Monitor system sundhed

Vores monitor-system overvåger sig selv:

Fejldetektion:

Automatisk opdagelse af interne fejl
Fuld logging af alle exceptions
Stack traces til debugging

Administrator-alarmer:

Kritiske fejl emailes til systemadministrator
Rate-limiteret for at undgå spam
Detaljer inkluderet for hurtig løsning

Automatisk Recovery:

Cron fortsætter ved fejl i enkelte monitors
Ingen cascade-fejl på tværs af monitors
Database-transaktioner sikrer data-integritet

Uptime-mål

Vi sigter efter følgende pålidelighed:

Monitor-system uptime:

Mål: 99.9% (mindre end 9 timer nedetid per år)
Overvåget: Via interne logs og systemmålinger

Tjek-eksekveringsrate:

Mål: 99.5% succesrate for tjek-eksekvering
Overvåget: Fejlrate i logs

Tjek-pålidelighed: Overvågningen kører løbende; ved tekniske problemer alerteres administrator, så systemet holdes stabilt.

Almindelige scenarier og eksempler

Scenarie 1: Transient netværk blip

Situation: Kortvarigt netværksproblem, site er faktisk oppe.

00:00 - Tjek fejler (timeout) → Fejltæller: 1, Status: UP
00:05 - Tjek succeeds → Fejltæller: 0, Status: UP

Resultat:
✅ Ingen notifikation sendt
✅ Ingen status-ændring
✅ Ingen falsk alarm

Hvorfor det virker: 2-tjek-tærskel fanger kortvarige problemer.

Scenarie 2: Reel nedetid

Situation: Serveren er virkelig nede (f.eks. hosting-problem).

00:00 - Tjek fejler (HTTP 500) → Fejltæller: 1, Status: UP
      → System logger første fejl til intern overvågning

00:05 - Tjek fejler (timeout) → Fejltæller: 2, Status: DOWN
      → Incident oprettet automatisk
      → Notifikation sendt via email/Slack/webhook

00:10 - Tjek fejler (timeout) → Fejltæller: 3, Status: DOWN
      → Incident-varighed opdateres løbende

Resultat:
✅ DOWN-status bekræftet ved 00:05
✅ Notifikation sendt ~5 minutter efter første fejl
✅ Forskellige fejltyper (500 + timeout) tæller begge

Hvorfor det virker: To på hinanden følgende fejl bekræfter reelt problem.

Scenarie 3: Hurtig genoprettelse

Situation: Site nede, kommer hurtigt tilbage.

00:00 - Status er DOWN (fra tidligere fejl)
00:05 - Tjek succeeds (HTTP 200) → Fejltæller: 0, Status: UP
      → Incident markeres som løst automatisk
      → Recovery-notifikation sendt

Resultat:
✅ Øjeblikkelig genoprettelse ved første succesfulde tjek
✅ Incident-varighed beregnet (00:00 til 00:05 = 5 min)
✅ Du informeres hurtigt om recovery

Hvorfor det virker: Ingen 2-tjek-tærskel for genoprettelse.

Scenarie 4: Manuel refresh under første fejl

Situation: Automatisk tjek fejlede én gang, bruger vil verificere.

00:00 - Automatisk tjek fejler → Fejltæller: 1, Status: UP
      → Status forbliver UP (venter på bekræftelse)

00:02 - Du klikker "Opdater nu" → Tjek fejler → Status: DOWN omgående
      → Manuel tjek bypass 2-tjek-tærskel for hurtig feedback
      → Notifikation sendt

Resultat:
✅ Manuel tjek giver øjeblikkelig feedback
✅ Status opdateres uden at vente på næste automatiske tjek
✅ Nyttigt til debugging og verifikation

Hvorfor det virker: Manuelle tjek er designet til øjeblikkelig feedback.

Scenarie 5: Monitor-system fejl

Situation: Intern fejl i PingPuffin's egen kode.

00:00 - Monitor-system kører automatisk tjek
      → Intern fejl detekteres
      → Fejl fanges automatisk

      Logging:
      → Fejl logges med fuld kontekst til intern overvågning
      → Fuld teknisk information gemt til debugging

      Administrator-alarm:
      → Email sendt til systemadministrator (max 1 per time)
      → Indeholder fejl-detaljer og kontekst

      Database:
      → Ingen opdatering af din site status
      → Din site status forbliver uændret
      → Fejltæller påvirkes ikke

Resultat:
✅ Monitor-fejl påvirker IKKE din site-status
✅ Administrator alerteret for at kunne fikse problemet
✅ Ingen falsk DOWN-status

Hvorfor det virker: Skelnen mellem monitor-fejl og site-fejl.

Scenarie 6: Forskellige fejltyper på hinanden følgende

Situation: Server ustabil, forskellige fejl hver gang.

00:00 - Tjek fejler (HTTP 500) → Fejltæller: 1, Status: UP
00:05 - Tjek fejler (Connection timeout) → Fejltæller: 2, Status: DOWN
00:10 - Tjek fejler (HTTP 503) → Fejltæller: 3, Status: DOWN

Resultat:
✅ Forskellige fejltyper tæller ALLE med
✅ Status DOWN efter 2 fejl (uanset type)
✅ Indikerer ustabil server (måske værre end én konsistent fejl)

Hvorfor det virker: Enhver fejl betyder site ikke fungerer korrekt.

Ofte Stillede Spørgsmål

Hvor hurtigt får jeg besked om nedetid?

Automatisk tjek: ~5-10 minutter efter første fejl (kræver 2 fejl).
Manuel tjek: Øjeblikkeligt hvis du opdaterer manuelt.

Kan jeg få falske alarmer?

Meget sjældent. 2-tjek-systemet eliminerer langt de fleste kortvarige problemer. Hvis du får en alarm, er der næsten altid et reelt problem.

Hvad hvis min server er midlertidigt langsom?

Hvis svartiden overstiger timeout (standard 30 sek), tæller det som fejl. Du kan øge timeout-værdien for dit monitor.

Hvordan håndteres planlagt vedligeholdelse?

Brug "Snooze"-funktionen til at slå notifikationer fra i 24 timer. Overvågning fortsætter, men du får ingen alarmer.

Kan jeg se historik for alle tjek?

Ja, aktivitetsloggen viser alle tjek og status-ændringer. Du kan også eksportere til CSV.

Hvad sker der hvis PingPuffin selv går ned?

Vores monitors kører på pålidelig infrastruktur. Ved kritiske systemfejl alerteres administrator, men dit site markeres IKKE som nede.

Kontakt & Support

Har du spørgsmål til, hvordan overvågningen fungerer?

📧 Email: support@pingpuffin.com
🐛 Bug reports: Via email
📚 Dokumentation: Se dokumentationssektionen for mere information

Changelog

v1.5 (20. februar 2026)

SMS og WhatsApp tilføjet som notifikationskanaler (under Integrations)
SSL-certifikat-advarer: notifikation 8 dage og 2 dage før certifikat udløber (alle kanaler)
Langsom svartid: mulighed for at få alarm ved langsom respons (indstillinger, 5–15 sek)
Offentlige status-sider: beskrevet tilpasning med visningsnavn og logo, samt sprog
Tekniske implementeringsdetaljer fjernet fra brugerdokumentationen (fokus på hvad du oplever og kan indstille)

v1.3 (14. februar 2026)

Versions- og dokumentationsdato opdateret

v1.2 (9. februar 2026)

Ny sektion: Forventede HTTP-statuskoder med fuld standardliste (200, 201, 202, 203, 204, 205, 206, 301, 302, 303, 304, 307, 308) og tilpasning
Manuel "Opdater nu": dokumentation af "Sidst tjekket" og "Opdateret lige nu"-feedback i oversigten

v1.1 (17. januar 2026)

Verificeringer kører nu i parallel (hurtigere gennemløb)
Tjek-interval reduceret fra 5 til 3 minutter
Hver kategori kan tjekke op til 200 monitors per kørsel
Dokumentation opdateret med parallel processing detaljer

v1.0 (21. november 2024)

Første version af dokumentation
2-tjek verifikationssystem implementeret
Monitor-fejl beskyttelse tilføjet
Rate-limiterede administrator-alarmer

Dette dokument opdateres løbende. Tjek "Sidst opdateret" øverst for at se, om der er nye versioner.

Sådan fungerer PingPuffins overvågningssystem

Indholdsfortegnelse

Oversigt

Nøglefunktioner

Hvorfor gennemsigtighed er vigtigt

Tjek-intervaller og hyppighed

Automatiske tjek

Manuel opdatering

Dækning

Fejldetektion

2-tjek verifikationssystem

Hvordan det fungerer

Hvorfor 2-tjek?

Hvad tæller som en fejl?

HTTP-fejlkoder

Netværksfejl

SSL/TLS-fejl

Langsom svartid

Håndtering af forskellige fejltyper

Genoprettelse og statusændringer

Øjeblikkelig genoprettelse

Status-tilstande

🟢 UP (Oppe)

🔴 DOWN (Nede)

🟡 WARNING (Advarsel)

🔵 REDIRECT (Omdirigering)

Cloudflare-beskyttede Sites

Manuel opdatering

Bruger-initierede tjek

Anvendelsestilfælde

Forventede HTTP-statuskoder

Standard accepterede koder

Brugerdefinerede forventede statuskoder

Hvor det gælder

Beskyttelse mod monitor-fejl

Intern vs. ekstern fejl

Site-fejl (overvåges)

Monitor-system-fejl (beskyttet)

Administrator-alarmering

Notifikationssystem

Hvornår notifikationer sendes

Notifikationskanaler

E-mail

Slack

SMS

WhatsApp

Webhook

Notifikation snoozing

Offentlige status-sider

Automatiske dashboard-opdateringer

Auto-refresh mekanisme

Hvad opdateres?

Dataindsamling og lagring

Tjek-poster

Incident tracking

Aktivitetslog

Tekniske specifikationer

HTTP request-parametre

Forventede HTTP-statuskoder

Svartidsmåling

Avancerede overvågningsindstillinger

HTTP-metode

Request body

Basic authentication

Future features

Serverinformationer

Offentlig IP-adresse

Privatliv og sikkerhed

Datakryptering

Dataadgang

HTTPS enforcement

Systempålidelighed

Monitor system sundhed

Uptime-mål

Almindelige scenarier og eksempler

Scenarie 1: Transient netværk blip

Scenarie 2: Reel nedetid

Scenarie 3: Hurtig genoprettelse

Scenarie 4: Manuel refresh under første fejl

Scenarie 5: Monitor-system fejl