Til oppetidsovervågning er det korte svar: 2xx-svar betyder oppe, 5xx-svar betyder nede, og alt derimellem afhænger af, hvad du forventer af den URL. En 301 er i orden, hvis siden er flyttet med vilje, en 401 er i orden på et API-endpoint, der kræver en nøgle, og en 404 på din checkout-side er et nedbrud. Den rigtige monitor tjekker for den statuskode, du forventer, ikke bare for “alt andet end en fejl”.
Dette snydeark gennemgår statuskodefamilierne set fra et overvågningsperspektiv: hvad hver kode betyder, om den skal tælle som nede, og hvordan du sætter tjek op, så de kun alarmerer ved reelle problemer.
De fem familier i overblik
IntervalBetydningFor en monitor1xxInformation, forespørgslen fortsætterSes sjældent; ikke et endeligt svar2xxSuccesSom regel oppe3xxRedirect, se et andet stedOppe eller nede afhængigt af hensigten4xxKlientfejl, forespørgslen var forkertAfhænger af endpointet5xxServerfejl, serveren fejledeNede
Det første ciffer fortæller, hvem der har ansvaret. 4xx betyder, at serveren mener, forespørgslen var forkert. 5xx betyder, at serveren erkender, at den fejlede. For en monitor, der sender den samme forespørgsel hvert minut, betyder en pludselig 4xx som regel alligevel, at noget er ændret på serversiden: en side er fjernet, en tilladelse er ændret, eller en firewall er begyndt at blokere.
1xx: information
Koder som 100 Continue, 101 Switching Protocols og 103 Early Hints er foreløbige svar. En klient ser dem før det endelige svar eller slet ikke. Et overvågningstjek venter på den endelige statuskode, så du kan se bort fra denne familie. Hvis et tjek nogensinde ender på en 1xx, blev forbindelsen afbrudt midt i svaret, og det er en fejl.
2xx: succes
KodeNavnNoter til overvågning200OKStandardsvaret ved succes201CreatedForventet efter en POST, der opretter noget202AcceptedForespørgslen er sat i kø; arbejdet sker senere204No ContentSucces med tom body; almindelig ved DELETE og nogle health checks
En 200 er ingen garanti for, at siden virker. Mange applikationer fanger deres egne fejl og viser en fejlside med status 200: “Database connection failed”, en tom skabelon, en vedligeholdelsesmeddelelse. Tilføj indholdsvalidering til vigtige tjek: forvent et ord eller et JSON-felt, der kun dukker op, når siden virkelig virker. Med 204 er der ingen body at validere, så tjek kun statuskoden.
3xx: redirects
KodeNavnTypisk brug301Moved PermanentlyGammel URL til ny URL, HTTP til HTTPS302FoundMidlertidig redirect, ofte til en login-side303See OtherRedirect efter en POST fra en formular304Not ModifiedDen cachede kopi er stadig gyldig; kun efter betingede forespørgsler307Temporary RedirectSom 302, men bevarer metode og body308Permanent RedirectSom 301, men bevarer metode og body
Redirects og monitorer
Overvågningsværktøjer håndterer redirects på en af to måder: de følger dem og rapporterer status for den endelige side, eller de stopper ved det første svar og rapporterer 3xx-koden. Vid, hvad dit værktøj gør for hvert tjek, for begge dele kan skjule problemer:
Hvis monitoren følger redirects, kan en side, der pludselig sender videre til forsiden eller en login-skærm, stadig ende i en 200. Indholdsvalidering fanger det: forsiden indeholder ikke ordene fra din checkout-side.
Hvis monitoren ikke følger redirects, så sæt den forventede status til redirect-koden, og tjek den endelige URL med sin egen monitor.
Det sikreste mønster er at overvåge den endelige URL direkte. Hvis northwind.shop sender videre til www.northwind.shop, så overvåg www-versionen, og tilføj kun et separat tjek af redirecten, hvis den betyder noget for dig, fx for gamle kampagnelinks. Et redirect-loop, hvor to URL’er peger på hinanden, viser sig som en timeout eller en “too many redirects”-fejl og bør altid tælle som nede.
4xx: klientfejl
KodeNavnNede?400Bad RequestSom regel et defekt tjek eller et ændret API401UnauthorizedForventet på beskyttede endpoints uden loginoplysninger403ForbiddenForventet for blokerede stier; et problem, hvis den pludselig dukker op404Not FoundNede for enhver URL, der burde findes405Method Not AllowedTjekket bruger den forkerte metode, eller ruten er ændret408Request TimeoutServeren gav op med at vente på forespørgslen410GoneFjernet med vilje429Too Many RequestsRate-begrænset
401 og 403 på beskyttede endpoints
Nogle endpoints skal afvise anonyme forespørgsler. Et admin-API, der returnerer 401 uden token, fungerer korrekt. Du kan overvåge det på to måder:
Forvent afvisningen. Sæt den forventede status til 401. Tjekket bekræfter, at serveren er oppe, og at godkendelseslaget er på plads. Hvis det nogensinde returnerer 200 uden loginoplysninger, er det et sikkerhedsproblem, der fortjener en alarm.
Send loginoplysninger. Tilføj en API-nøgle-header eller basic auth til tjekket, og forvent 200 plus det rigtige indhold. Det tester hele vejen, inklusive databasen bag endpointet.
Den anden mulighed tester mere, så brug den til alt, hvad kunderne er afhængige af. Brug en dedikeret skrivebeskyttet nøgle til overvågning, aldrig en personlig nøgle eller en admin-nøgle.
En pludselig 403 på en offentlig side er en anden sag. Det betyder som regel, at en firewall, et sikkerhedsplugin eller en CDN-regel er begyndt at blokere forespørgsler, nogle gange kun fra bestemte lande eller IP-intervaller. Hvis én overvågningslokation får 403 og en anden får 200, er en geo- eller IP-regel den sandsynlige årsag.
429 Too Many Requests
En 429 betyder, at serveren rate-begrænser klienten. For overvågning betyder det en af to ting: dine grænser er for stramme til normal trafik, eller monitoren rammer selv en grænse, fordi den deler adresse med andre klienter. Tjek Retry-After-headeren og din rate limit-konfiguration. Hvis rigtige brugere får 429 ved normal belastning, så behandl det som et nedbrud.
5xx: serverfejl
KodeNavnHvad det som regel betyder500Internal Server ErrorApplikationen crashede på denne forespørgsel501Not ImplementedServeren understøtter ikke metoden502Bad GatewayProxyen fik et ugyldigt svar fra appen bag den503Service UnavailableOverbelastet, under vedligeholdelse eller ingen sund backend504Gateway TimeoutProxyen ventede for længe på appen
Behandl enhver 5xx som nede. Koderne adskiller sig i, hvor du skal kigge først: en 500 peger på applikationslogs, en 502 på en applikationsproces, der er crashet eller genstarter, en 504 på langsomme forespørgsler eller eksterne kald, og en 503 på kapacitet eller vedligeholdelse. Vores guide til fejlen 503 Service Unavailable gennemgår årsager og løsninger i detaljer.
Nogle CDN’er og proxyer bruger deres egne koder i 5xx-intervallet, fx 520 til 530, for problemer mellem CDN’et og din origin-server. De er ikke en del af HTTP-standarden, men for en besøgende betyder de det samme: websitet er nede.
Ikke alle fejl har en statuskode
Nogle af de mest almindelige nedbrud giver slet ingen statuskode:
DNS-fejl: domænet kan ikke slås op, fx efter en udløbet registrering eller en fjernet record.
Forbindelse afvist eller nulstillet: intet lytter på porten, eller en firewall afbryder forbindelsen.
TLS-fejl: et udløbet eller forkert certifikat stopper forespørgslen, før der overhovedet sker noget HTTP.
Timeouts: serveren accepterer forbindelsen, men svarer aldrig i tide.
En god monitor rapporterer dem som fejl med den faktiske fejlmeddelelse, så alarmen siger “certifikatet er udløbet” i stedet for bare “nede”. Det er også derfor, det er værd at tilføje tjek af certifikat- og domæneudløb ved siden af dine HTTP-monitorer.
Sådan sætter du den forventede status i en monitor
For hver URL, du overvåger, så beslut, hvordan et sundt svar ser ud, og skriv det ned som tjekkets konfiguration:
Vælg den URL, der betyder noget. Den endelige URL efter redirects, ikke det korte link.
Vælg metoden. GET for sider og det, endpointet kræver, for API’er.
Sæt den forventede status. Som regel 200. Brug 201, 204, 301 eller 401, når det er det tilsigtede svar.
Tilføj loginoplysninger om nødvendigt. Headers eller basic auth til beskyttede endpoints.
Tilføj indholdsvalidering. Et ord på siden eller et felt i JSON-svaret, der kun dukker op, når alt virker.
Sæt en timeout. Et svar, der tager 30 sekunder, er en fejl for en besøgende, selv hvis det ender i 200.
Sådan ser det ud for et health-endpoint på lumenanalytics.io, testet manuelt først med curl:
curl -sS -o /dev/null -w “%{http_code} %{time_total}s\n” \
-H “Authorization: Bearer $MONITOR_TOKEN” \
https://api.lumenanalytics.io/v1/health
Hvis det udskriver 200 og en rimelig tid, kommer samme metode, header og forventede status ind i monitoren. I Uptimecheck accepterer oppetidsmonitorer og API-monitorer en brugerdefineret metode, headers (fx basic auth eller et bearer-token), body, nøgleord og JSON-tjek, og de lader tjekket fejle, når statuskoden eller svaret ikke er, som du forventer. Vil du vide mere om at designe selve endpointet, så se sådan bygger du et health check-endpoint og tjeklisten til API-overvågning for, hvilke endpoints du skal dække.
Hurtigt overblik: er det nede?
Nede: enhver 5xx, en 404 på en URL, der burde findes, timeouts, DNS- og TLS-fejl, afviste forbindelser.
Sandsynligvis nede: en pludselig 403 eller 429 på en offentlig side, en 400 eller 405 på et tjek, der plejede at bestå.
Oppe: den statuskode, du har sat som forventet, med det indhold, du validerer for, inden for en rimelig tid.
Opsummering
Statuskoder er det første, en monitor kigger på, og den hurtigste måde at se, hvor et problem ligger. 5xx betyder, at serveren fejlede, 4xx betyder, at noget er ændret i, hvad serveren accepterer, og 3xx kræver en beslutning om, hvor tjekket skal ende. Konfigurer hver monitor med den status, den skal få, valider indholdet af vigtige sider, og lad alarmen indeholde koden, så den, der tager den, ved, hvor der skal startes.
Uptimecheck tjekker dine websites og API’er helt ned til hvert minut og giver dig besked, når statuskoden eller svaret ikke er, som du forventer. Prøv det gratis i 14 dage, uden kreditkort.