API-overvåking betyr å sende ekte forespørsler til API-et ditt med jevne mellomrom og sjekke at svarene er riktige, ikke bare at serveren svarte. Et API som returnerer 200 OK med en tom liste, en feilmelding i innholdet eller et svar som tar ti sekunder, er ødelagt for appene som er avhengige av det, selv om en enkel sjekk ville gått gjennom. Denne sjekklisten viser hva du bør sette opp, slik at API-monitorene dine fanger opp de reelle problemene.
1. Velg endepunktene
Ikke overvåk alt. Overvåk det brukere og integrasjoner er avhengige av:
Health- eller statusendepunkt, hvis det sjekker avhengigheter som databasen. Et health-endepunkt som bare returnerer «ok» uten å sjekke noe, forteller deg lite.
Autentisering: endepunktet som utsteder tokens eller validerer økter. Feiler det, feiler alt.
Sentrale leseendepunkter: de appen din kaller på hver skjerm, som å liste ordrer eller hente en profil.
Kritiske skriveflyter: kasse, registrering eller webhook-mottakere, overvåket med testdata. En flytmonitor kjører en slik rekke API-kall steg for steg, tar med verdier som et token eller en ordre-ID fra ett steg til det neste og holder hemmeligheter forseglet.
Tredjeparts-API-er du er avhengig av, som betalings- eller fraktleverandører, slik at du vet når problemet ikke er ditt. Uptimechecks overvåking av tredjepartstjenester følger statussidene til 31 tjenester som Klarna, Shopify og Cloudflare, eller en hvilken som helst side på Statuspage.
2. Sett opp forespørselen: metode, headere og innhold
En sjekk bør se ut som en ekte forespørsel fra en klient:
Metode: GET for lesing, POST, PUT eller PATCH for endepunkter som krever det.
Headere: Accept: application/json, en Content-Type for forespørsler med innhold, og eventuelle egne headere API-et ditt krever, som en versjonsheader.
Innhold: en liten, gyldig payload for POST-forespørsler, for eksempel et søk.
Velg forespørsler som er trygge å gjenta hvert minutt. Unngå endepunkter som oppretter ekte ordrer, sender e-poster eller belaster kort, med mindre du bruker en egen testkonto.
3. Håndter autentisering
De fleste API-er krever påloggingsinformasjon. Alternativer:
Basic auth for enkle, beskyttede endepunkter.
API-nøkkel eller bearer-token i en header, for eksempel Authorization: Bearer <token>.
Opprett en egen konto eller et eget token for overvåking med kun lesetilgang. Det begrenser skaden hvis tokenet lekker, og holder overvåkingstrafikken atskilt i loggene dine. Husk at tokens utløper. Et langvarig token med kun lesetilgang til overvåking unngår falske alarmer når et kortvarig token går ut.
4. Valider statuskoden
Bestem hvilke statuskoder som betyr suksess. Vanligvis er det 200, 201 eller 204, avhengig av endepunktet. Vær forsiktig med videresendinger: et API som plutselig sender videre til en innloggingsside, returnerer en 3xx og deretter en 200 med HTML. Det er et utfall for enhver app som forventer JSON.
5. Valider innholdet i svaret
Det er her de fleste API-sjekker kommer til kort. Sjekk at svaret inneholder noe bare et fungerende API ville returnert:
Et felt som alltid skal være med, som «status»:»ok» eller «id».
En kjent verdi fra testdata.
At feiltekst mangler, som «error».
Med Uptimecheck angir du forventede statuskoder, et nøkkelord og JSON-sjekker for hver API-monitor, for eksempel at $.status er lik ok eller at en header finnes, sammen med metode, headere (inkludert basic auth eller et bearer-token) og innhold.
6. Sett terskler for responstid
For API-er er tregt det nye nede. Mobilapper får tidsavbrudd og integrasjoner prøver på nytt, noe som gir enda mer last. Registrer responstiden ved hver sjekk og sett en terskel basert på hva som er normalt:
Se på en uke med responstider for å finne utgangspunktet.
Sett en varslingsterskel godt over normal variasjon, for eksempel to til tre ganger den vanlige responstiden.
Varsle om vedvarende treghet, ikke enkeltstående topper. Én treg forespørsel er støy, en hel rekke av dem er et problem.
I Uptimecheck setter du en grense for treg respons per monitor, og du får et varsel om treghet når tre sjekker på rad er tregere enn den, og et nytt når det går raskere igjen.
Sjekker fra mer enn én region viser om tregheten er global eller begrenset til én nettverksvei. Uptimecheck sjekker fra Stockholm, London og New York og deler hver responstid opp i DNS, tilkobling, TLS, server og nedlasting, slik at du ser når tregheten starter og hvor tiden går.
7. Overvåk hele kjeden
Et API feiler sjelden alene. Legg til monitorer for det det er avhengig av:
SSL-sertifikater på API-ets vertsnavn. Et utløpt sertifikat ødelegger for alle klienter på én gang.
DNS-poster for API-ets domene.
Serverressurser som CPU, minne og disk på API-serverne.
Planlagte jobber som holder dataene oppdatert, med heartbeats.
8. Send varsler til de rette personene
API-varsler hører vanligvis til utviklerne som eier tjenesten. Send dem til teamets chattekanal, og til en kanal som når en telefon ved produksjonsutfall om natten. Bruk webhooks for å sende varsler inn i ditt eget verktøy for hendelseshåndtering. Se varsler.
9. Automatiser oppsettet av monitorer
Hvis du ofte ruller ut nye tjenester, kan du opprette monitorer som en del av utrullingen. Uptimechecks REST API (Professional og Business) dekker monitorer, vedlikeholdsvinduer og statusoppdateringer, dokumentert på app.uptimecheck.com/docs/api, slik at overvåking kan være en del av pipelinen din i stedet for et manuelt steg i etterkant. En MCP-server lar AI-assistenter gjøre det samme med en API-nøkkel.
10. Fortell API-brukerne hva som skjer
Hvis andre team eller kunder bygger på API-et ditt, gi dem en statusside med en komponent for API-et. Da slipper de å feilsøke sin egen kode mens det er du som har utfall.
Vanlige feil ved API-overvåking
Å bare sjekke health-endepunktet. Health-endepunkter går ofte gjennom mens de ekte endepunktene feiler fordi en avhengighet er nede.
Å bruke produksjonspålogging for en ekte bruker. Når den brukeren bytter passord eller slutter, slutter overvåkingen å virke. Bruk en egen konto.
Å ignorere innholdet. En HTML-feilside med status 200 går gjennom en sjekk som bare ser på statusen.
Å varsle om hvert trege svar. Enkeltstående topper skaper støy og lærer folk å ignorere varsler.
Å glemme avhengigheter. API-et er i orden, men sertifikatet har utløpt eller DNS-posten er endret.
Sjekklisten
Velg endepunkter: health, autentisering, sentrale lesinger, kritiske skrivinger, viktige tredjeparts-API-er.
Angi metode, headere og innhold for hver sjekk.
Bruk et eget token med kun lesetilgang eller egen påloggingsinformasjon for basic auth.
Definer de forventede statuskodene.
Valider innholdet: et felt eller en verdi som bare et fungerende API returnerer.
Registrer responstiden og varsle om vedvarende treghet.
Sjekk fra mer enn én region.
Overvåk SSL, DNS, servere og planlagte jobber bak API-et.
Send varsler til teamet som eier tjenesten, med en kanal som når telefonen for produksjon.
Opprett monitorer via API-et som en del av utrullingene.
Oppsummering
En 200 OK er starten på en API-sjekk, ikke slutten. Send realistiske forespørsler, valider innholdet, følg med på responstiden og dekk kjeden bak API-et.
API-overvåking med egne metoder, headere, forespørselsinnhold, JSON-sjekker og varsler om treg respons er en del av alle Uptimecheck-planer. Prøv gratis i 14 dager, uten kredittkort.