Oppetidsovervåking av nettsider sender en forespørsel til siden din etter en fast tidsplan og sjekker svaret. Hvis svaret er feil, tregt eller mangler, får du et varsel. Det høres enkelt ut, og det er det. Verdien ligger i detaljene: hvor ofte du sjekker, hva som regnes som feil, hvordan en feil bekreftes, og hvor raskt riktig person får beskjed.
Uptimecheck kjører HTTP(S)-, ping- og portsjekker hvert 1., 2., 5., 10., 15. eller 30. minutt eller hver time. Hver sjekk registrerer statuskoden og responstiden, så du ser både driftsavbrudd og trege perioder. Vil du ha bakgrunnen først, kan du lese hva oppetidsovervåking er og hvorfor det betyr noe.
Typer sjekker
HTTP(S): be om en URL med GET, POST eller en annen metode, send egne headere og egen body, og sjekk statuskoden, et nøkkelord eller JSON-felt i svaret.Ping: bekreft at en vert svarer på nettverket, med tur-retur-tiden.Port: sjekk at en tjeneste, for eksempel en e-postserver eller en database, tar imot tilkoblinger.
For brukerreiser som går over flere sider, som innlogging eller kassen, bruker du flytovervåking.
Hvorfor sjekke hvert minutt, og sjekke to ganger
Nedetid koster penger for hvert minutt. Hvis kassen svarer 503 klokken 03:12 og ingen merker det før den første supporthenvendelsen, har du tapt timer i stedet for minutter. Guiden vår om hva nedetid på nettsiden koster går gjennom tallene.
Uptimecheck sjekker fra Stockholm, London og New York, og bekrefter hver feil fra et annet sted før en hendelse åpnes. Det kutter falske alarmer fra en enkelt tapt forespørsel eller et kort nettverkshikk, mens et ekte driftsavbrudd likevel når deg i løpet av et minutt eller to. Guiden vår om å redusere falske varsler forklarer hvorfor det er viktig.
Fra feilet sjekk til løst problem
03:12: sjekken av northwind.shop/checkout returnerer 503.03:12: den andre sjekken feiler også. En hendelse åpnes med det feilende svaret og et skjermbilde av det besøkende så.03:13: utvikleren som har vakt, får et push-varsel på telefonen, og teamkanalen får detaljene i Slack.03:19: sjekkene går gjennom igjen. Et gjenopprettingsvarsel sendes med den totale nedetiden.
Varsler går til e-post, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks og push-varsler på telefonen, på alle planer. Se varsler og meldinger for ruting og eskalering, hendelseshåndtering for hva som skjer etter varselet, og kombiner overvåkingen med en statusside, så kundene vet hva som skjer uten å sende en henvendelse.
Responstider, delt opp i faser
Hver HTTP-sjekk lagrer responstiden, delt opp i DNS, tilkobling, TLS, server og nedlasting. En treg serverfase peker mot applikasjonen din; treg DNS eller TLS peker mot infrastrukturen. Grafene viser median, 95-persentil og gjennomsnitt, så en treg hale ikke gjemmer seg bak et godt gjennomsnitt. Les mer om responstid for nettsider.
Sett en grense, for eksempel 2 000 ms, så får du et varsel om treghet når tre sjekker på rad er tregere enn det, og et nytt når siden blir rask igjen. Treg tid regnes ikke som nedetid.
Monitorens side viser de siste sjekkene. Tre eller flere like sjekker på rad slås sammen til én linje, for eksempel «OK · 200 × 18» med spennet i responstider, og kan åpnes for å vise hver sjekk. En feil slås aldri sammen med en rekke vellykkede sjekker, og den andre sjekken som bekrefter en feil, får sin egen linje. Hvis en monitor som ikke er satt på pause, ikke har blitt sjekket på dobbelt så lang tid som intervallet, viser siden «No recent data» med tidspunktet for siste sjekk, så en gammel status aldri utgir seg for å være gjeldende.
Sjekk at siden faktisk fungerer
En side kan svare 200 og likevel være ødelagt: en tom produktliste, en feilmelding, en vedlikeholdsside. Legg til svarsjekker som alle må bestå:
Forventet status: koder eller intervaller, for eksempel 200-299 eller 200,301.Nøkkelord: tekst siden må eller ikke må inneholde, for eksempel «Legg i handlekurven».JSON og headere: for API-er, et felt som $.status er lik ok, eller en header som må være med.
HTTPS-monitorer leser også sertifikatet og minner deg på det før det utløper. Se SSL-overvåking.
Sett opp din første monitor
Legg inn URL-en, velg type sjekk, angi hva som regnes som et gyldig svar, og velg hvilke kanaler som skal varsles. «Test request» viser svaret før du lagrer, og den første sjekken kjører med en gang. De fleste team starter med tre monitorer: forsiden, den viktigste konverteringssiden (kasse, registrering eller innlogging) og det viktigste API-endepunktet. Bytter du fra UptimeRobot, Better Stack, Pingdom eller StatusCake? Importer monitorene dine med innstillingene og se hver eneste en før noe opprettes.
Hva som regnes som nede
En sjekk feiler når forespørselen får tidsavbrudd, tilkoblingen avvises, sertifikatet er ugyldig, statuskoden ikke er den du forventer, eller en svarsjekk ikke holder. Oppetid er andelen av tiden uten et bekreftet driftsavbrudd, og vedlikeholdsvinduer teller ikke mot den. Rapportene viser oppetid per monitor for en valgfri periode mot SLA-målet ditt, med CSV-eksport.
Planene starter på 9 € i måneden ved årlig fakturering eller 12 € ved månedlig fakturering, ekskl. mva., med sjekker hvert minutt på alle betalte planer, eller gratis for 5 monitorer som sjekkes hvert 5. minutt. Sammenlign monitorer, statussider og historikk (1, 2 eller 3 år) på prissiden, se deg rundt i live-demoen uten å registrere deg, eller start en 14 dagers gratis prøveperiode uten kort.