Upptidsövervakning av en webbplats skickar en förfrågan till sajten enligt ett fast schema och kontrollerar svaret. Är svaret fel, långsamt eller uteblir det får du ett larm. Det låter enkelt, och det är det. Värdet sitter i detaljerna: hur ofta du kontrollerar, vad som räknas som fel, hur ett fel bekräftas och hur snabbt rätt person får veta det.
Uptimecheck kör HTTP(S)-, ping- och portkontroller varje, varannan, var 5:e, 10:e, 15:e eller 30:e minut eller en gång i timmen. Varje kontroll sparar statuskoden och svarstiden, så att du ser både avbrott och perioder då sajten är långsam. Vill du ha bakgrunden först kan du läsa vad upptidsövervakning är och varför det spelar roll.
Typer av kontroller
HTTP(S): anropa en URL med GET, POST eller en annan metod, skicka egna headers och en egen body, och kontrollera statuskoden, ett nyckelord eller JSON-fält i svaret.Ping: bekräfta att en värd svarar i nätverket, med svarstiden tur och retur.Port: kontrollera att en tjänst, till exempel en e-postserver eller en databas, tar emot anslutningar.
För flöden som sträcker sig över flera sidor, till exempel inloggning eller kassa, använder du flödesövervakning.
Varför kontrollera varje minut, och två gånger
Driftstopp kostar pengar för varje minut. Om kassan svarar 503 klockan 03:12 och ingen märker det förrän det första supportärendet kommer in har du förlorat timmar i stället för minuter. Vår guide om vad driftstopp kostar går igenom siffrorna.
Uptimecheck kontrollerar från Stockholm, London och New York och bekräftar varje fel från en andra plats innan en incident öppnas. Det minskar falsklarm från en enstaka tappad förfrågan eller en kort nätverksstörning, medan ett verkligt avbrott ändå når dig inom en eller två minuter. Vår guide om att minska antalet falsklarm förklarar varför det spelar roll.
Från misslyckad kontroll till åtgärdat
03:12: kontrollen av northwind.shop/checkout returnerar 503.03:12: den andra kontrollen misslyckas också. En incident öppnas med det felande svaret och en skärmbild av det besökarna såg.03:13: utvecklaren med jour får en pushnotis i mobilen, och teamets kanal får detaljerna i Slack.03:19: kontrollerna går igenom igen. Ett återställningsmeddelande skickas med den totala nedtiden.
Larmen går till e-post, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks och pushnotiser i mobilen, på alla planer. Se larm och notiser för routning och eskalering, incidenthantering för vad som händer efter larmet, och kombinera övervakningen med en statussida så att kunderna vet vad som händer utan att skicka ett ärende.
Svarstider uppdelade i faser
Varje HTTP-kontroll sparar sin svarstid uppdelad i DNS, anslutning, TLS, server och nedladdning. En långsam serverfas pekar mot din applikation; långsam DNS eller TLS pekar mot infrastrukturen. Graferna visar median, 95:e percentil och medelvärde, så att en långsam svans inte gömmer sig bakom ett bra snitt. Läs mer om svarstid för webbplatser.
Sätt en gräns, till exempel 2 000 ms, så får du ett larm om långsamhet när tre kontroller i rad är långsammare än så, och ett till när sajten blir snabb igen. Långsam tid räknas inte som nedtid.
Monitorns sida listar de senaste kontrollerna. Tre eller fler likadana kontroller i rad slås ihop till en rad, till exempel ”OK · 200 × 18” med intervallet för svarstiderna, och kan fällas ut för att visa varje kontroll. Ett fel slås aldrig ihop med en rad godkända kontroller, och den andra kontrollen som bekräftar ett fel behåller sin egen rad. Om en monitor som inte är pausad inte har kontrollerats på dubbla sitt intervall visar sidan ”Inga aktuella data” med tiden för den senaste kontrollen, så att en gammal status aldrig ser ut som en aktuell.
Kontrollera att sidan verkligen fungerar
En sida kan svara 200 och ändå vara trasig: en tom produktlista, ett felmeddelande, en underhållssida. Lägg till svarskontroller som alla måste gå igenom:
Förväntad status: koder eller intervall, till exempel 200-299 eller 200,301.Nyckelord: text som sidan måste eller inte får innehålla, till exempel ”Lägg i varukorgen”.JSON och headers: för API:er, att ett fält som $.status är ok, eller att en viss header finns.
HTTPS-monitorer läser också certifikatet och påminner dig innan det går ut. Se SSL-övervakning.
Skapa din första monitor
Lägg till URL:en, välj typ av kontroll, ange vad som räknas som ett giltigt svar och välj vilka kanaler som ska larmas. ”Testa förfrågan” visar svaret innan du sparar, och den första kontrollen körs direkt. De flesta team börjar med tre monitorer: startsidan, den viktigaste konverteringssidan (kassa, registrering eller inloggning) och den viktigaste API-endpointen. Byter du från UptimeRobot, Better Stack, Pingdom eller StatusCake? Importera dina monitorer med deras inställningar och se varenda en innan något skapas.
Vad räknas som nere
En kontroll misslyckas när förfrågan får timeout, anslutningen nekas, certifikatet är ogiltigt, statuskoden inte är den du förväntar dig eller en svarskontroll inte håller. Upptid är andelen tid utan bekräftat avbrott, och underhållsfönster räknas inte emot den. Rapporterna visar upptid per monitor för valfri period mot ditt SLA-mål, med export till CSV.
Planerna börjar på 9 € i månaden vid årsbetalning eller 12 € vid månadsbetalning, exkl. moms, med kontroller varje minut på alla betalda planer, eller gratis för 5 monitorer som kontrolleras var 5:e minut. Jämför monitorer, statussidor och historik (1, 2 eller 3 år) på prissidan, titta runt i livedemon utan att registrera dig, eller starta en gratis provperiod på 14 dagar utan kort.