Agencies 7 min lesing

Hva bør du overvåke på nettstedet? En sjekkliste over URL-er og sjekker

Overvåker du bare forsiden, går du glipp av de fleste driftsstansene. En sjekkliste over URL-ene og sjekkene som betyr noe, fra innlogging og kasse til webhooks, cron-jobber, SSL, DNS og servere, med eksempeloppsett.

Overvåk mer enn forsiden. Et komplett oppsett dekker forsiden, alle konverteringsveier (innlogging, registrering, kasse og søk), API-endepunktene appene dine er avhengige av, betalingscallbacks og webhooks, planlagte jobber, SSL-sertifikater, domeneregistrering, DNS-oppføringer inkludert MX, serverne under og tredjepartstjenestene du er avhengig av. Et nettsted for en liten bedrift trenger en håndfull sjekker; en nettbutikk eller et SaaS-produkt trenger noen dusin. Begynn med det som tjener penger, og legg deretter til det som kan utløpe eller feile i det stille. For helhetsbildet kan du lese hvordan pålitelig oppetidsovervåking hjelper nettstedet ditt å prestere.

Denne sjekklisten går gjennom hvert punkt, forklarer hva du bør sjekke og hvorfor, og avslutter med eksempeloppsett for et lite nettsted, en nettbutikk, et SaaS-produkt og et byrå, pluss en navnekonvensjon som holder alt oversiktlig.

1. Forsiden

Forsiden er den åpenbare første monitoren, og en god en: er den nede, er alt nede. Men den leveres ofte fra et CDN eller en sidebuffer, så den kan holde seg oppe mens applikasjonen bak feiler. Overvåk den med en HTTP(S)-sjekk hvert minutt, og valider et stykke stabilt innhold, for eksempel firmanavnet i bunnteksten, slik at en bufret feilside ikke regnes som oppe. Gå deretter videre til sidene som forteller deg mer.

2. Konverteringsveier

Dette er sidene som tjener penger eller holder på kundene, og de er avhengige av databasen, øktene og applikasjonskoden som forsiden kanskje hopper over:

Innlogging: viser at økter og brukerdatabasen fungerer. Overvåk innloggingssiden og valider at skjemaet er der.

Registrering: starten for hver ny kunde.

Handlekurv og kasse: for en nettbutikk de viktigste sidene på nettstedet. Overvåk selve kassesiden, ikke bare produktsidene.

Søk: drives ofte av en egen tjeneste, så det kan feile for seg selv. Overvåk en URL for søkeresultater med et søk som alltid gir treff, og valider at et resultat vises.

Booking- eller kontaktskjemaer, hvis det er slik henvendelsene kommer inn.

Sjekk disse hvert minutt. For de fleste bedrifter koster en kasse som ikke virker, mer per minutt enn noe annet på denne listen. Oppetidsovervåkingen i Uptimecheck støtter egne metoder og headere og validerer statuskoden, nøkkelord og JSON på hver side. For å sjekke at innlogging eller kasse faktisk fungerer, ikke bare at siden laster, går en flytmonitor gjennom den steg for steg, eventuelt i en ekte nettleser, med verdier som tas med mellom stegene og hemmeligheter som holdes forseglet.

3. API-endepunkter

Har du en mobilapp, en single-page-frontend eller partnerintegrasjoner, er API-et produktet. Overvåk:

Et health-endepunkt som sjekker databasen, cachen og disken. Se hvordan du bygger et health check-endepunkt.

Det viktigste leseendepunktet, med API-nøkkel-headeren klientene dine sender.

Ett skriveendepunkt, med en trygg testpayload, hvis skriving er kritisk.

Valider svarinnholdet, ikke bare statuskoden: et API som returnerer 200 med en feilmelding, er fortsatt nede. API-overvåking og sjekklisten for API-overvåking går dypere.

4. Betalingscallbacks og webhooks

Betalingsleverandører, frakttjenester og andre plattformer kaller tilbake til nettstedet ditt for å bekrefte ordrer og oppdatere status. Slutter det mottakende endepunktet å virke, kan betalinger gå gjennom uten at ordrene noen gang blir merket som betalt. Ingen ser noen feilside, fordi ingen besøkende er involvert.

Du kan vanligvis ikke sende en ekte callback fra en monitor, men du kan sjekke at endepunktet svarer. Mange webhook-mottakere returnerer en 4xx-kode for en forespørsel uten gyldig signatur; er det det forventede svaret, overvåker du etter det. En 5xx eller et tidsavbrudd betyr da at selve mottakeren er ødelagt. Kombiner det med leverandørens egne leveringslogger, som viser mislykkede callbacks fra deres side.

5. Cron-jobber og bakgrunnsarbeid

Sikkerhetskopier, importer, fakturakjøringer, feedeksporter, nyhetsbrevutsendelser og køarbeidere har ingen URL å sjekke. De feiler i det stille. Gi hver av dem en heartbeat: jobben kaller en unik URL når den er ferdig, og et varsel sendes når kallet ikke kommer i tide. Uptimecheck-planene teller heartbeats separat fra monitorer, så dette spiser ikke av sjekkene for nettstedet ditt.

6. SSL-sertifikater

Et utløpt sertifikat viser alle besøkende en helsides advarsel i nettleseren og stopper API-klienter helt. Overvåk sertifikatet på hvert vertsnavn du leverer, inkludert www, API-subdomenet, domenet for statussiden og administrasjonspaneler, og få påminnelser flere uker før utløp. Automatisk fornyelse gjør utløp sjeldnere, ikke umulig. Se overvåking av utløp for SSL-sertifikater for de vanlige feilårsakene.

7. Domeneregistrering

Når en domeneregistrering utløper, stopper nettstedet, e-posten og API-et på domenet samtidig. Påminnelser fra registraren går ofte til en gammel adresse. Følg med på utløpsdatoen for hvert domene du eier, inkludert landsvarianter, kampanjedomener og gamle merkenavn som fortsatt videresender.

8. DNS-oppføringer, inkludert MX

DNS avgjør hvor trafikk og e-post havner. Følg med på endringer i:

A og AAAA: hvor nettstedet lastes fra.

NS: hvem som kontrollerer sonen. En endring her er alltid verdt en titt.

MX: hvem som mottar e-posten din, inkludert ordrebekreftelser og tilbakestilling av passord.

TXT: SPF, DKIM og DMARC. En fjernet oppføring kan sende e-posten din rett i søppelposten. Domenemonitoren i Uptimecheck sjekker også SPF, DKIM og DMARC to ganger om dagen og forteller hvordan du løser hvert problem, med en DNS-oppføring klar til å lime inn der en slik løser det; se overvåking av e-postautentisering.

CNAME og CAA: CDN-aliaser og hvilke sertifikatutstedere som kan utstede sertifikater for domenet.

En uventet endring er enten en feil eller et angrep. DNS-overvåking varsler deg med gammel og ny verdi. Driver du din egen e-postserver, bør du også legge til en portsjekk på den, for eksempel SMTP på port 465.

9. Servere

Driver du egne servere eller VPS-er, bør du overvåke CPU, minne, disk, nettverk og omstarter. Slik fanger du opp årsakene til nedetid før de blir symptomer: en disk som blir full på torsdag, en minnelekkasje, en omstart der en tjeneste ikke startet igjen. Serverovervåking ligger ved siden av oppetidssjekkene dine, så årsak og symptom vises på samme skjerm. Med fullt administrert hosting kan du ofte hoppe over dette og stole på leverandøren.

10. Avhengigheter til tredjeparter

Nettstedet ditt er avhengig av tjenester du ikke drifter selv: betalingsleverandører, e-postlevering, søk, et headless CMS, en autentiseringsleverandør, et CDN. Når en av dem feiler, kan nettstedet ditt laste mens funksjonen bak er ødelagt. Overvåk de offentlige endepunktene du er avhengig av, eller dine egne endepunkter som bruker dem, slik at du i løpet av minutter kan fortelle en kunde om problemet ligger hos deg eller hos leverandøren. Legg disse på en varslingskanal med lavere prioritet, siden du ikke kan fikse dem selv.

Tredjepartsovervåkingen i Uptimecheck følger statussidene til 31 tjenester som Klarna, Swish, Shopify, Cloudflare og OpenAI, eller en hvilken som helst side på Statuspage, slik at hendelsene deres vises ved siden av dine egne monitorer.

11. Nettstedshelse

Noen problemer tar aldri ned en side: en død lenke etter en migrering, et bilde som lastes over vanlig HTTP, en side som ble tregere etter en ny plugin. En daglig skanning fanger dem opp. Monitoren for nettstedshelse i Uptimecheck gjennomsøker nettstedet ditt og sitemapet hver dag etter døde lenker og blandet innhold, og måler sidehastighet og Core Web Vitals med Google Lighthouse på mobil og desktop.

Hvor mange monitorer trenger du?

Oppsettene nedenfor er eksempler du kan tilpasse, ikke faste oppskrifter:

Type nettstedEksempeloppsettNettsted for en liten bedrift, for eksempel fjordstudio.seForside, side med kontaktskjema, SSL, domene, DNS for A og MX, én heartbeat for sikkerhetskopien. Rundt 3 HTTP-monitorer pluss utløps- og DNS-sjekkene.Nettbutikk, for eksempel northwind.shopForside, en kategoriside, produktside, handlekurv, kasse, innlogging, søk, betalingscallback, health-endepunkt, SSL på hvert vertsnavn, domene, DNS, heartbeats for sikkerhetskopier, feedeksporter og ordresynkronisering, og serverne. Omtrent 10 til 15 HTTP-monitorer.SaaS-produkt, for eksempel lumenanalytics.ioMarkedsføringsnettsted, innlogging i appen, registrering, API-helse, de viktigste API-endepunktene, webhook-mottaker, statusside, SSL, domener, DNS, heartbeats for hver worker og planlagte jobb, og servere. Ofte 15 til 40 monitorer.ByråOppsettet for små nettsteder for hver kunde, pluss kasse og innlogging for kundenes nettbutikker, gruppert per kunde. Vanligvis noen få monitorer per kunde, ganget med antall kunder.

Begynn med konverteringsveiene og utløpssjekkene, kjør i to uker, og legg deretter til det du skulle ønske du hadde hatt under den første hendelsen.

Navnekonvensjoner

Navnet på en monitor er det første noen leser i et varsel midt på natten. La det svare på «hva gikk i stykker, hvor, og hvor ille» uten at man må åpne noe:

[client or product] – [environment] – [what] – [check type]

Northwind – prod – Checkout – HTTPS
Northwind – prod – Payment callback – HTTPS
Northwind – prod – Nightly backup – heartbeat
Lumen – prod – API health – HTTPS
Lumen – staging – API health – HTTPS
Fjord Studio – prod – MX record – DNS

Bruk samme rekkefølge overalt, slik at varsler kan skummes og sorteres.

Gi ting navn slik teamet snakker om dem, ikke etter interne vertsnavn.

Merk miljøer tydelig, slik at et varsel fra staging aldri ser ut som produksjon.

For byråer: begynn med kundenavnet og grupper monitorene per kunde i prosjekter, slik at hver kundes monitorer og varsler holdes samlet.

Sjekklisten

Forside, med innholdsvalidering.

Innlogging, registrering, kasse og søk.

API-helse og de viktigste endepunktene.

Betalingscallbacks og webhook-mottakere.

En heartbeat for hver planlagte jobb som betyr noe.

SSL på hvert vertsnavn og registreringen av hvert domene.

DNS-oppføringer: minst A, AAAA, NS, MX og TXT.

Servere, hvis du driver egne.

Viktige tredjepartstjenester, på en kanal med lavere prioritet.

Nettstedshelse: døde lenker, blandet innhold og sidehastighet, skannet daglig.

Tydelige navn, og varsler som går til den som eier hvert punkt.

Uptimecheck dekker nettsteder, API-er, flyter i flere steg, heartbeats, SSL, domener, DNS, servere, tredjepartstjenester og nettstedshelse i én konto. Start en gratis prøveperiode på 14 dager, uten kredittkort.

Spørsmål

Holder det å overvåke forsiden?

Nei. Forsiden er ofte bufret og kan holde seg oppe mens innlogging, kasse eller API-et bak feiler. Overvåk også sidene og endepunktene som tjener penger.

Hvor mange monitorer trenger et nettsted?

Det avhenger av nettstedet. Et nettsted for en liten bedrift kan klare seg med tre HTTP-monitorer pluss SSL-, domene- og DNS-sjekker, mens en nettbutikk eller et SaaS-produkt ofte trenger 10 til 40 monitorer og flere heartbeats.

Hvordan overvåker jeg en betalingswebhook?

Sjekk at det mottakende endepunktet svarer med det svaret det gir en usignert forespørsel, ofte en 4xx-kode. En 5xx eller et tidsavbrudd betyr da at mottakeren er ødelagt. Gå også gjennom leverandørens leveringslogger.

Hvordan bør jeg navngi monitorene mine?

Bruk ett konsekvent mønster, for eksempel kunde eller produkt, miljø, hva som sjekkes og type sjekk. Navnet skal fortelle vakthavende hva som gikk i stykker, uten at dashbordet må åpnes.

Les videre

Nedetid er fortid.

Sett opp din første monitor på under ett minutt, eller se deg rundt i livedemoen først.

14 dagers gratis prøveperiode · Deretter gratis for 5 monitorer · Uten kredittkort