API-overvågning betyder, at du sender rigtige forespørgsler til dit API med faste mellemrum og tjekker, at svarene er korrekte, ikke bare at serveren svarede. Et API, der returnerer 200 OK med en tom liste, en fejlbesked i body’en eller et svar, der tager ti sekunder, er i stykker for de apps, der er afhængige af det, selvom et simpelt check ville bestå. Denne tjekliste gennemgår, hvad du skal konfigurere, så dine API-monitorer fanger de rigtige problemer.
1. Vælg endpoints
Overvåg ikke alt. Overvåg det, som brugere og integrationer er afhængige af:
Health- eller status-endpoint, hvis det tjekker afhængigheder som databasen. Et health-endpoint, der bare returnerer “ok” uden at tjekke noget, fortæller dig ikke meget.
Autentificering: det endpoint, der udsteder tokens eller validerer sessioner. Hvis det fejler, fejler alt.
Centrale læse-endpoints: dem, din app kalder på hver skærm, f.eks. til at vise ordrer eller hente en profil.
Kritiske skrivestier: kasse, tilmelding eller webhook-modtagere, overvåget med testdata. En flowmonitor kører sådan en række API-kald trin for trin, fører værdier som et token eller et ordre-ID videre fra ét trin til det næste og holder hemmeligheder forseglet.
Tredjeparts-API’er, du er afhængig af, f.eks. betalings- eller fragtudbydere, så du ved, når problemet ikke er dit. Uptimechecks overvågning af tredjepartstjenester følger statussiderne for 31 tjenester som Klarna, Shopify og Cloudflare, eller enhver side hostet på Statuspage.
2. Opsæt forespørgslen: metode, headers og body
Et check skal ligne en rigtig klientforespørgsel:
Metode: GET til læsning, POST, PUT eller PATCH til endpoints, der kræver dem.
Headers: Accept: application/json, en Content-Type til forespørgsler med en body og eventuelle egne headers, dit API kræver, f.eks. en versions-header.
Body: en lille, gyldig payload til POST-forespørgsler, f.eks. en søgeforespørgsel.
Vælg forespørgsler, der er sikre at gentage hvert minut. Undgå endpoints, der opretter rigtige ordrer, sender e-mails eller trækker penge på kort, medmindre du bruger en dedikeret testkonto.
3. Håndtér autentificering
De fleste API’er kræver login-oplysninger. Mulighederne:
Basic auth til enkle, beskyttede endpoints.
API-nøgle eller bearer token i en header, f.eks. Authorization: Bearer <token>.
Opret en dedikeret overvågningskonto eller et token med skrivebeskyttede rettigheder. Det begrænser skaden, hvis tokenet lækker, og holder overvågningstrafikken adskilt i dine logs. Husk, at tokens udløber. Et langtidsholdbart, skrivebeskyttet token til overvågning undgår falske alarmer, når et kortlivet token løber ud.
4. Valider statuskoden
Beslut, hvilke statuskoder der betyder succes. Som regel er det 200, 201 eller 204, afhængigt af endpointet. Vær forsigtig med redirects: Et API, der pludselig omdirigerer til en login-side, returnerer en 3xx og derefter en 200 med HTML. Det er et nedbrud for enhver app, der forventer JSON.
5. Valider svarets indhold
Det er her, de fleste API-checks kommer til kort. Tjek, at svaret indeholder noget, som kun et fungerende API ville returnere:
Et felt, der altid skal være der, f.eks. “status”:”ok” eller “id”.
En kendt værdi fra testdata.
Fravær af fejltekst, f.eks. “error”.
Med Uptimecheck angiver du de forventede statuskoder, et nøgleord og JSON-checks for hver API-monitor, f.eks. at $.status er lig med ok, eller at en header findes, sammen med metode, headers (inklusive basic auth eller et bearer token) og body.
6. Sæt grænser for svartid
For API’er er langsom det nye nede. Mobilapps får timeout, og integrationer prøver igen, hvilket giver endnu mere belastning. Registrér svartiden ved hvert check, og sæt en grænse ud fra, hvad der er normalt:
Se på en uges svartider for at finde dit udgangspunkt.
Sæt en alarmgrænse et godt stykke over den normale variation, f.eks. to til tre gange den sædvanlige svartid.
Alarmér på vedvarende langsomhed, ikke på enkelte udsving. Én langsom forespørgsel er støj, en hel række af dem er et problem.
I Uptimecheck sætter du en grænse for langsomme svar pr. monitor, og du får en alarm, når tre checks i træk er langsommere end grænsen, og en ny, når det bliver hurtigt igen.
Checks fra mere end én region viser, om langsomheden er global eller begrænset til én netværksvej. Uptimecheck tjekker fra Stockholm, London og New York og opdeler hver svartid i DNS, forbindelse, TLS, server og download, så du kan se, hvornår langsomheden begynder, og hvor tiden går.
7. Overvåg hele kæden
Et API fejler sjældent alene. Tilføj monitorer for det, det er afhængigt af:
SSL-certifikater på API’ets hostname. Et udløbet certifikat sætter alle klienter ud af spil på én gang.
DNS-records for API’ets domæne.
Serverressourcer som CPU, hukommelse og disk på API-serverne.
Planlagte jobs, der holder data opdateret, med heartbeats.
8. Send alarmer til de rette personer
API-alarmer hører som regel til hos de udviklere, der ejer tjenesten. Send dem til teamets chatkanal og til en kanal, der når frem til en telefon, når produktion går ned om natten. Brug webhooks til at sende alarmer videre til dine egne incident-værktøjer. Se notifikationer.
9. Automatisér opsætningen af monitorer
Hvis du ofte deployer nye tjenester, så opret monitorer som en del af deployet. Uptimechecks REST API (Professional og Business) dækker monitorer, vedligeholdelsesvinduer og statusopdateringer og er dokumenteret på app.uptimecheck.com/docs/api, så overvågning kan være en del af din pipeline i stedet for et manuelt trin bagefter. En MCP-server lader AI-assistenter gøre det samme med en API-nøgle.
10. Fortæl API-brugerne, hvad der sker
Hvis andre teams eller kunder bygger på dit API, så giv dem en statusside med en komponent for API’et. Det sparer dem for at debugge deres egen kode under dit nedbrud.
Typiske fejl i API-overvågning
Kun at tjekke health-endpointet. Health-endpoints består ofte, mens de rigtige endpoints fejler, fordi en afhængighed er nede.
At bruge en rigtig brugers produktionslogin. Når brugeren skifter adgangskode eller stopper, holder overvågningen op med at virke. Brug en dedikeret konto.
At ignorere body’en. En HTML-fejlside med status 200 består et check, der kun ser på statussen.
At alarmere på hvert langsomt svar. Enkelte udsving skaber støj og lærer folk at ignorere alarmer.
At glemme afhængighederne. API’et er fint, men certifikatet er udløbet, eller DNS-recorden er ændret.
Tjeklisten
Vælg endpoints: health, autentificering, centrale læsninger, kritiske skrivninger og vigtige tredjeparts-API’er.
Angiv metode, headers og body for hvert check.
Brug et dedikeret, skrivebeskyttet token eller basic auth-login.
Definér de forventede statuskoder.
Valider indholdet: et felt eller en værdi, som kun et fungerende API returnerer.
Registrér svartiden, og alarmér på vedvarende langsomhed.
Tjek fra mere end én region.
Overvåg SSL, DNS, servere og planlagte jobs bag API’et.
Send alarmer til det team, der ejer tjenesten, med en telefonvenlig kanal til produktion.
Opret monitorer via API’et som en del af dine deploys.
Opsummering
En 200 OK er begyndelsen på et API-check, ikke slutningen. Send realistiske forespørgsler, valider indholdet, hold øje med svartiden, og dæk kæden bag API’et.
API-overvågning med egne metoder, headers, bodies, JSON-checks og alarmer for langsomme svar er med i alle Uptimechecks planer. Prøv det gratis i 14 dage, uden kreditkort.