Svarstidövervakning

Varför svarstid förtjänar en egen varning

Standardmässiga uptime-varningar bygger på en binär signal: uppe eller nere. Den grå zonen däremellan – uppe, men långsam – är där de flesta moderna driftstörningar faktiskt lever. En felkonfigurerad databasfråga börjar ta 4 sekunder istället för 50 ms. Minnesläcka orsakar ryckvis garbage collection. Ett externt API som backend ropar till börjar blinka. Inget av detta förstör sidan helt, men gör den oanvändbar – och dessa är tidiga tecken på ett haveri som kommer om en timme eller två.

Övervakning av svarstid fångar upp försämringar innan det blir ett avbrott. Du konfigurerar en tröskel per monitor, och när svarstiden överskrider den under flera på varandra följande kontroller får du en varning. Innan varningen skickas har du fortfarande tid att undersöka, skala upp, throtla det problematiska anropet eller rulla tillbaka en deploy som orsakade det.

Hur trösklar fungerar i DiagnoSEO Uptime Monitoring

Varje monitor kan konfigureras med två parametrar: rt_threshold_ms och rt_threshold_breaches. Den första är svarstiden i millisekunder som du anser är acceptabel. Den andra är hur många på varandra följande kontroller som måste överskrida den för att en varning ska skickas. Som standard är tröskeln avstängd och antalet överskridanden tre.

Den tvådelade designen skyddar mot falska larm. Nätverksjitter händer. Pauser i garbage collection händer. Ett enstaka hopp till 1 sekund när normalt 200 ms inte är värt en personsökare klockan 3 på natten. Men tre på varandra följande svar på 1 sekund – det är en varaktig försämring, inte en fluktuation. Välj en tröskel baserat på observerat normalt beteende plus en lämplig marginal: om p95 normalt är 400 ms, tröskel vid 1000 ms. Om p95 är 50 ms (internt API), tröskel vid 200 ms.

Vad fungerar det bra med

Svarstidsvarningar fungerar bäst i kombination med andra övervakningssignaler. En helhetsbild: svarstidströskeln visar att systemet degraderas; HTTP-koden visar när det faktiskt går sönder; SSL/domänvarningar för klockstyrda avbrott; DNS-ändringsvarningar för konfigurationsdrift. Tillsammans ger fyra signaler på samma monitor en full observability istället för binärt "fungerar eller inte".

Instrumentpanelen hjälper också här. Varje monitor visar ett sparkline-diagram för senaste svarstider – en snabb visuell indikator på mönster av försämring. Den utökade vyn visar snitt för 24 timmar, 7 dagar och 30 dagar. Om du ser medelvärdet krypa upp vecka efter vecka är det ett tidigt tecken värt att undersöka innan varningströskeln passeras.

Praktiska trösklar efter sidtyp

• Marknadsföringssidor (landningssidor): 1500 ms är rimligt. De är tunga med bilder och spårningsskript; absolut hastighet är mindre viktig än stabilitet.
• Produktsidor/e-handelskategorier: 800–1200 ms. Långsam e-handel dödar konverteringar; snävare trösklar fångar problem snabbare.
• Applikationsdashboardar: 500–800 ms. Användare förväntar sig responsivitet. Långsamma dashboards får produkten att kännas trasig.
• Publikt API: 200–400 ms för enkla endpoints, högre för beräkningskrävande. Dela upp i nivåer.
• Interna mikrotjänsters health checks: 50–100 ms. Ska vara nästan omedelbara; långsamhet betyder nästan alltid verkligt problem.

Vad du än väljer – välj inte bara en gång och glöm bort. Omvärdera kvartalsvis baserat på verkliga trender. Om du ständigt får tröskelvarningar som inte är riktiga problem – tröskeln är för snäv. Får du ett avbrott utan att tröskelvarning gått före – då var tröskeln för generös.

Routing av varningar

Tröskelvarningar går samma kanaler som down/recovery-varningar: e-post, Telegram, Slack, Discord, SMS. De respekterar samma nattläge. De loggas i samma varningstabell. Enda skillnaden är händelsetypen ("threshold" istället för "down") och meddelandets innehåll – det anger aktuell svarstid och tröskelvärde så att du direkt ser hur stort överskridandet är.

Konfiguration

Redigera valfri monitor. Ställ in "Svarstidströskel (ms)" i formuläret till önskat värde. Anpassa vid behov "antal på varandra följande överskridanden" om standardvärdet 3 inte passar. Spara. Från nästa cykel jämför varje kontroll svarstid mot tröskeln, och efter inställt antal på varandra följande överskridanden får du en notifiering.

Vanliga frågor och svar

• Vilken metrik för svarstid loggas?

  Time To First Byte (TTFB) — millisekunder mellan att förfrågan skickas och första byte i svaret mottas. Plus total tid för nedladdning av fullt svar. TTFB är den mest användbara enskilda metrik för serverns hälsa.

• Vad är en "bra" svarstid?

  Beroende av plats och innehåll. För en statisk sida med CDN: under 100 ms är utmärkt, under 300 ms OK. För dynamiska applikationer: under 500 ms är OK, under 1000 ms acceptabelt, över 2000 ms upplevs som långsamt. Jämför med din egen historik snarare än absoluta tal.

• Kan jag få en varning om svarstiden passerar tröskeln?

  Ja. Varje monitor har en valfri svarstidströskel. Om 3 på varandra följande kontroller överskrider tröskeln får du en "slow response"-varning. Kravet på 3 kontroller förebygger falsklarm från tillfälliga nätverksbortfall.

• Varifrån mäts svarstiden?

  Från våra 13 geografiska kontrollpunkter (Europa, Nordamerika, Asien, Sydamerika, Oceanien). För single-region-monitors tas tider från närmaste region. För multi-region mäts varje region oberoende – användbart för att upptäcka regionala CDN-problem.

• Visar dashboarden trender för svarstid?

  Ja – 30-dagars glidande medelvärde, dagliga max/min och percentiler (p50, p95). Användbart för kapacitetsplanering: om p95 ökat från 800 ms till 1500 ms under en månad är dina servrar överbelastade trots att uptime-procenten är 100 %.