API-övervakning innebär att du skickar riktiga anrop till ditt API med jämna mellanrum och kontrollerar att svaren är korrekta, inte bara att servern svarade. Ett API som svarar 200 OK med en tom lista, ett felmeddelande i svaret eller ett svar som tar tio sekunder är trasigt för apparna som är beroende av det, även om en enkel kontroll skulle godkänna det. Den här checklistan går igenom vad du ska ställa in så att dina API-monitorer fångar verkliga problem.
1. Välj endpoints
Övervaka inte allt. Övervaka det som användare och integrationer är beroende av:
Hälso- eller status-endpoint, om den kontrollerar beroenden som databasen. En hälso-endpoint som bara svarar ”ok” utan att kontrollera något säger dig inte mycket.
Autentisering: den endpoint som utfärdar tokens eller validerar sessioner. Om den slutar fungera slutar allt att fungera.
Centrala läs-endpoints: de som din app anropar på varje skärm, till exempel för att lista ordrar eller hämta en profil.
Kritiska skrivflöden: kassa, registrering eller webhook-mottagare, övervakade med testdata. En flödesmonitor kör en sådan sekvens av API-anrop steg för steg, för vidare värden som en token eller ett order-ID från ett steg till nästa och håller hemligheter förseglade.
Tredjeparts-API:er du är beroende av, till exempel betal- eller fraktleverantörer, så att du vet när problemet inte ligger hos dig. Uptimechecks övervakning av tredjepartstjänster följer statussidorna för 31 tjänster som Klarna, Shopify och Cloudflare, eller vilken sida som helst som ligger på Statuspage.
2. Ställ in anropet: metod, headers och body
En kontroll ska se ut som ett riktigt anrop från en klient:
Metod: GET för läsningar, POST, PUT eller PATCH för endpoints som kräver det.
Headers: Accept: application/json, en Content-Type för anrop med body och de egna headers som ditt API kräver, till exempel en versions-header.
Body: en liten, giltig payload för POST-anrop, till exempel en sökfråga.
Välj anrop som är säkra att upprepa varje minut. Undvik endpoints som skapar riktiga ordrar, skickar mejl eller drar pengar från kort, om du inte använder ett separat testkonto.
3. Hantera autentisering
De flesta API:er kräver inloggningsuppgifter. Alternativ:
Basic auth för enkla skyddade endpoints.
API-nyckel eller bearer token i en header, till exempel Authorization: Bearer <token>.
Skapa ett separat konto eller en separat token för övervakning, med enbart läsbehörighet. Det begränsar skadan om token läcker och håller övervakningstrafiken åtskild i dina loggar. Kom ihåg att tokens går ut. En långlivad token med enbart läsbehörighet för övervakning undviker falsklarm när en kortlivad token löper ut.
4. Validera statuskoden
Bestäm vilka statuskoder som betyder att allt gick bra. Oftast är det 200, 201 eller 204, beroende på endpoint. Var försiktig med omdirigeringar: ett API som plötsligt omdirigerar till en inloggningssida svarar med en 3xx och sedan en 200 med HTML. Det är ett avbrott för varje app som väntar sig JSON.
5. Validera innehållet i svaret
Det är här de flesta API-kontroller brister. Kontrollera att svaret innehåller något som bara ett fungerande API skulle returnera:
Ett fält som alltid ska finnas, till exempel ”status”:”ok” eller ”id”.
Ett känt värde från testdata.
Att det inte finns någon feltext, till exempel ”error”.
Med Uptimecheck anger du förväntade statuskoder, ett nyckelord och JSON-kontroller för varje API-monitor, till exempel att $.status är lika med ok eller att en header finns, tillsammans med metod, headers (inklusive basic auth eller en bearer token) och body.
6. Sätt gränser för svarstid
För API:er är långsamt det nya nere. Mobilappar får timeout och integrationer gör om anropen, vilket ökar belastningen ytterligare. Registrera svarstiden vid varje kontroll och sätt en gräns utifrån vad som är normalt:
Titta på en veckas svarstider för att hitta normalnivån.
Sätt en larmgräns en bra bit över den normala variationen, till exempel två till tre gånger den vanliga svarstiden.
Larma om ihållande långsamhet, inte om enstaka toppar. Ett långsamt anrop är brus, en hel rad av dem är ett problem.
I Uptimecheck sätter du en gräns för långsamma svar per monitor, och du får ett larm när tre kontroller i rad är långsammare än gränsen, och ett nytt när det blir snabbare igen.
Kontroller från fler än en region visar om långsamheten är global eller begränsad till en nätverksväg. Uptimecheck kontrollerar från Stockholm, London och New York och delar upp varje svarstid i DNS, anslutning, TLS, server och nedladdning, så att du ser när långsamheten börjar och vart tiden tar vägen.
7. Övervaka hela kedjan
Ett API slutar sällan fungera på egen hand. Lägg till monitorer för det som det är beroende av:
SSL-certifikat på API:ets värdnamn. Ett utgånget certifikat slår ut alla klienter på en gång.
DNS-poster för API:ets domän.
Serverresurser som CPU, minne och disk på API-servrarna.
Schemalagda jobb som håller data aktuell, med heartbeats.
8. Skicka larmen till rätt personer
API-larm hör oftast till utvecklarna som äger tjänsten. Skicka dem till teamets chattkanal, och till en kanal som når en telefon för produktionsavbrott nattetid. Använd webhooks för att föra in larmen i ert eget incidentverktyg. Se aviseringar.
9. Automatisera uppsättningen av monitorer
Om du ofta driftsätter nya tjänster kan du skapa monitorer som en del av driftsättningen. Uptimechecks REST API (Professional och Business) täcker monitorer, underhållsfönster och statusuppdateringar och är dokumenterat på app.uptimecheck.com/docs/api, så att övervakningen kan vara en del av din pipeline i stället för ett manuellt steg efteråt. En MCP-server låter AI-assistenter göra samma sak med en API-nyckel.
10. Berätta för API:ets användare vad som händer
Om andra team eller kunder bygger på ditt API, ge dem en statussida med en komponent för API:et. Då slipper de felsöka sin egen kod under ditt avbrott.
Vanliga misstag vid API-övervakning
Att bara kontrollera hälso-endpointen. Hälso-endpoints svarar ofta att allt är bra medan de riktiga endpointsen fallerar för att ett beroende är nere.
Att använda en riktig användares inloggning i produktion. När den användaren byter lösenord eller slutar går övervakningen sönder. Använd ett separat konto.
Att strunta i svarets innehåll. En HTML-felsida med status 200 går igenom en kontroll som bara tittar på statusen.
Att larma vid varje långsamt svar. Enstaka toppar skapar brus och lär folk att ignorera larm.
Att glömma beroendena. API:et fungerar, men certifikatet har gått ut eller DNS-posten har ändrats.
Checklistan
Välj endpoints: hälsa, autentisering, centrala läsningar, kritiska skrivningar och viktiga tredjeparts-API:er.
Ställ in metod, headers och body för varje kontroll.
Använd en separat token med enbart läsbehörighet eller egna uppgifter för basic auth.
Ange vilka statuskoder du förväntar dig.
Validera innehållet: ett fält eller värde som bara ett fungerande API returnerar.
Registrera svarstiden och larma om ihållande långsamhet.
Kontrollera från fler än en region.
Övervaka SSL, DNS, servrar och schemalagda jobb bakom API:et.
Skicka larmen till teamet som äger tjänsten, med en kanal som når telefonen för produktion.
Skapa monitorer via API:et som en del av driftsättningen.
Sammanfattning
Ett 200 OK är början på en API-kontroll, inte slutet. Skicka realistiska anrop, validera innehållet, bevaka svarstiden och täck kedjan bakom API:et.
API-övervakning med egna metoder, headers, bodies, JSON-kontroller och larm om långsamma svar ingår i alla Uptimechecks planer. Prova gratis i 14 dagar, inget kreditkort behövs.