Monitoring API

Wiedz, kiedy Twoje API przestaje odpowiadać wcześniej niż Twoi użytkownicy

AlertSleep wysyła takie samo zapytanie jak Twoi klienci — dowolną metodą, z Twoimi nagłówkami, treścią i tokenem — i sprawdza kod statusu oraz odpowiedź. Gdy coś pójdzie nie tak, druga lokalizacja powtarza sprawdzenie, a Ty dostajesz SMS albo telefon.

Zacznij 14-dniowy okres próbny Zobacz Cennik
  • Sprawdzenie co 60 sekund
  • Każda awaria potwierdzana z drugiej lokalizacji
  • SMS-y i połączenia telefoniczne w cenie
api.example.com
Działa
GET /health 200 OK · 84 ms
POST /v1/quotes 200 OK · 142 ms
GET /v1/me 200 OK · 97 ms
108 ms
Śr. odpowiedź
100%
Dostępność, 30 dni
60 s
Interwał sprawdzeń

Co potrafi sprawdzenie API

Jeden monitor to jedno zapytanie HTTP, skonfigurowane tak, jak oczekuje tego Twoje API.

Dowolna metoda, nagłówki i treść

GET, POST, PUT, PATCH, DELETE, HEAD lub OPTIONS. Dodaj własne nagłówki, a do zapytań POST, PUT i PATCH treść w formacie JSON albo formularza.

Endpointy z uwierzytelnianiem

Wyślij token Bearer albo klucz API w nagłówku lub użyj Basic Auth. Nagłówki i hasła przechowujemy w postaci zaszyfrowanej.

Ty decydujesz, co oznacza sukces

Wybierz, które kody statusu oznaczają, że API działa. Każdy inny to awaria, a w alercie zobaczysz kod, który zwrócił serwer.

Sprawdzanie treści odpowiedzi

Monitor słowa kluczowego czyta też treść odpowiedzi i zgłasza awarię, gdy brakuje w niej wybranego tekstu, np. "status":"ok". Wielkość liter ma znaczenie.

Potwierdzenie z drugiej lokalizacji

Nieudane sprawdzenie od razu powtarzamy z drugiej, niezależnej lokalizacji, z tą samą metodą, nagłówkami, treścią i danymi logowania. Jeśli stamtąd zapytanie przejdzie, nikt nie zostaje obudzony.

Czasy odpowiedzi i timeouty

Każde sprawdzenie zapisuje czas odpowiedzi, który widzisz na wykresie i jako średnią. Ustaw timeout od 5 do 60 sekund, żeby zawieszony endpoint liczył się jako awaria.

Monitory, które warto ustawić

Sześć typowych sprawdzeń API i ich konfiguracja. Przykładowe adresy zamień na własne.

Endpoint health

GET https://api.example.com/health

Działa, gdy: 200

Najprostsze sprawdzenie, które mówi najwięcej. Niech /health odpytuje bazę danych i cache — wtedy 200 oznacza, że API naprawdę może pracować.

POST z treścią JSON

POST https://api.example.com/v1/quotes
Content-Type: application/json
{"sku": "TEST-1", "qty": 1}

Działa, gdy: 200 + "price"

Prawdziwe zapytanie, które przechodzi przez logikę biznesową. Nagłówek Content-Type dodaj samodzielnie, a monitorem słowa kluczowego wymagaj konkretnego pola w odpowiedzi.

Za uwierzytelnianiem

GET https://api.example.com/v1/me
Authorization: Bearer <token>

Działa, gdy: 200

Użyj tokenu wydanego wyłącznie do monitoringu. Wygasły lub unieważniony token zwraca 401, a sprawdzenie zgłasza to jako awarię — dowiesz się więc także wtedy, gdy przestaną działać dane dostępowe.

Zapytanie GraphQL

POST https://api.example.com/graphql
Content-Type: application/json
{"query": "{ health { status } }"}

Działa, gdy: 200 + "status":"OK"

GraphQL często odpowiada 200 nawet wtedy, gdy zapytanie się nie powiodło, a problem umieszcza w "errors". Słowo kluczowe sprawia, że sprawdzenie wymaga danych, o które pytasz.

Odbiornik webhooków

GET https://shop.example.com/webhooks/payments

Działa, gdy: 405

Twój endpoint dla webhooków płatności czy wysyłek przyjmuje tylko podpisane POST-y. Dodaj 405 do akceptowanych kodów: aplikacja, która odpowiada „method not allowed”, działa, a timeout albo 502 już nie.

API, od którego zależysz

GET https://status.example-provider.com/api/v2/status.json

Działa, gdy: 200 + "indicator":"none"

Wielu dostawców publikuje endpoint statusu w formacie JSON. Obserwuj go obok własnego API, a z alertu od razu wyczytasz, czy problem leży po Twojej stronie, czy po ich.

Co się dzieje, gdy sprawdzenie się nie powiedzie

  1. 1

    Wysyłamy Twoje zapytanie co 60 sekund

    Z naszego serwera, z ustawioną przez Ciebie metodą, nagłówkami, treścią i danymi logowania, a odpowiedź porównujemy z Twoimi regułami.

  2. 2

    Druga lokalizacja je powtarza

    Jeśli i tam się nie uda, incydent otwiera się od razu. Jeśli z drugiej lokalizacji zapytanie przejdzie, problem leży po naszej stronie sieci i alert nie wychodzi.

  3. 3

    Dostajesz alert z przyczyną

    SMS, telefon, e-mail albo czat zespołu, a w wiadomości konkretny błąd: kod statusu, timeout lub brakujące słowo kluczowe.

  4. 4

    I wiadomość, gdy wszystko wróci

    Powiadomienie o przywróceniu wychodzi po pierwszym udanym sprawdzeniu, a incydent zostaje w historii i w raporcie dostępności.

Co uznajemy za awarię

Alert zawiera komunikat zapisany przez sprawdzenie. Przykłady poniżej.

Kod statusu, którego nie akceptujesz

Serwer odpowiedział, ale żadnym z Twoich kodów — 500, 503 z load balancera, 401 po wygaśnięciu tokenu.

HTTP 503 Service Unavailable

Brak słowa kluczowego

Status był w porządku, ale w treści odpowiedzi zabrakło tekstu, którego wymaga monitor.

Keyword '"status":"OK"' not found in response

Brak odpowiedzi na czas

Endpoint nie odpowiedział w ustawionym czasie. To najczęstszy objaw przeciążonego API.

Connection failed: cURL error 28: Operation timed out after 30001 milliseconds

Brak jakiegokolwiek połączenia

Domena nie rozwiązuje się w DNS, port jest zamknięty albo połączenie zostaje odrzucone.

Connection failed: cURL error 6: Could not resolve host

Wadliwy certyfikat

Przy włączonej weryfikacji certyfikatu wygasły, samopodpisany lub niepasujący do domeny certyfikat kończy sprawdzenie błędem, tak samo jak u Twoich klientów.

Connection failed: cURL error 60: SSL certificate problem

Alerty i wszystko wokół nich

Monitoring API to połowa pracy. Druga połowa to dotarcie do właściwej osoby i cisza podczas planowanych prac.

Gdzie trafiają alerty

E-mail, SMS i połączenia telefoniczne, a do tego Slack, Microsoft Teams, Telegram, WhatsApp, Discord i Twój własny webhook.
Dowiedz się więcej

Okna serwisowe

Zaplanuj okno serwisowe na wdrożenie albo migrację. Sprawdzenia trwają dalej, ale alerty nie wychodzą, a planowane prace nie obniżają statystyki dostępności.

Strona statusu dla Twojego API

Opublikuj monitory na publicznej stronie statusu, żeby programiści korzystający z Twojego API mogli ją sprawdzić, zanim założą zgłoszenie.
Dowiedz się więcej

Nasze własne REST API

Twórz monitory, odczytuj sprawdzenia i incydenty oraz otwieraj okno serwisowe prosto z pipeline'u wdrożeniowego, za pomocą tokenu API.

Zadania w tle

Kolejek, importów i zadań uruchamianych według harmonogramu nie da się sprawdzić zapytaniem z zewnątrz. Monitor cron czeka na ich sygnał i wysyła alert, gdy sygnał nie dotrze.
Dowiedz się więcej

Certyfikat i domena

Ten sam monitor może pilnować certyfikatu API i rejestracji domeny oraz ostrzec Cię, zanim któreś z nich wygaśnie.
Dowiedz się więcej

Czego monitoring API nie robi

Lepiej wiedzieć o tym przed rejestracją niż po niej.

  • Jeden monitor wysyła jedno zapytanie. Nie ma sprawdzeń wieloetapowych, które logują się, przekazują token do kolejnego zapytania i weryfikują każdy krok.
  • Odpowiedź sprawdzamy po kodzie statusu, a w monitorze słowa kluczowego także po jednym tekście, który musi się w niej znaleźć. Nie ma walidacji schematu JSON ani asercji na poszczególnych polach.
  • Czas odpowiedzi jest zapisywany, ale nie wywołuje alertu. Wolny endpoint uruchomi alert dopiero wtedy, gdy przekroczy timeout.
  • Sprawdzenia wychodzą z jednej lokalizacji, a każdą awarię potwierdzamy z drugiej. To nie jest sieć punktów pomiarowych w wielu krajach.

Chcesz przetestować cały proces?

Wbuduj go w swoje API: endpoint /health/deep, który wykonuje cały proces wewnętrznie i zwraca 200 albo 500. AlertSleep sprawdza wtedy wynik co minutę i wysyła alert, gdy tylko się zmieni.

AlertSleep na tle konkurencji w monitoringu API

Najtańszy płatny plan każdej usługi: co może wysłać sprawdzenie API i jakie kanały alertów są w cenie.

Funkcja AlertSleep UptimeRobot Better Stack Pingdom
Własne nagłówki i kody statusu Tak Tak Tak Tak
Słowo kluczowe w odpowiedzi Tak Tak Tak Tak
Alerty SMS W cenie Pakiety kredytów Licencja na osobę 50 kredytów
Alerty telefoniczne Tak Pakiety kredytów Licencja na osobę Nie

Funkcje konkurencji dotyczą najtańszego płatnego planu, zgodnie z opisem na ich własnych stronach. Aktualne szczegóły sprawdź u źródła. (stan na: październik 2026)

Szczegółowe porównania: AlertSleep vs UptimeRobot · AlertSleep vs Better Stack · AlertSleep vs Pingdom

Najczęściej Zadawane Pytania

Czym jest monitoring dostępności API?
To usługa, która w stałych odstępach wysyła zapytanie do endpointu Twojego API i sprawdza odpowiedź. AlertSleep robi to co 60 sekund i wysyła alert, gdy endpoint zwróci kod statusu, którego nie akceptujesz, nie odpowie na czas, jest nieosiągalny albo w odpowiedzi brakuje wymaganego słowa kluczowego.

Czy AlertSleep monitoruje API z uwierzytelnianiem?
Tak. Dodaj nagłówek Authorization z tokenem Bearer, klucz API w dowolnym nagłówku albo dane Basic Auth. Przechowujemy je w postaci zaszyfrowanej i wysyłamy także przy sprawdzeniu potwierdzającym z drugiej lokalizacji. AlertSleep nie przechodzi przez proces OAuth, żeby zdobyć token, więc użyj długo ważnego tokenu wydanego do monitoringu.

Czy mogę monitorować zapytania POST i GraphQL?
Tak. Wybierz POST, PUT albo PATCH, wklej treść i dodaj nagłówek Content-Type. W przypadku GraphQL wyślij zapytanie jako JSON metodą POST i użyj monitora słowa kluczowego, żeby wymagać pola, o które pytasz, bo GraphQL często zwraca 200 razem z błędem.

Czy AlertSleep waliduje odpowiedź JSON?
Częściowo. Monitor słowa kluczowego wymaga w treści określonego tekstu, np. "status":"ok", i zgłasza awarię, gdy go brakuje. Nie ma walidacji schematu JSON ani asercji na ścieżkach. Jeśli ich potrzebujesz, sprawdzaj odpowiedź we własnym endpoincie health i niech zwraca on kod błędu.

Jak szybko AlertSleep wykryje awarię API?
Na każdym planie sprawdzamy co 60 sekund. Nieudane sprawdzenie od razu powtarzamy z drugiej lokalizacji, a gdy obie się zgadzają, alert wychodzi natychmiast. Zwykle wiesz o problemie w ciągu jednej, dwóch minut.

Które kody statusu oznaczają awarię?
Ty decydujesz. Domyślnie 200, 201, 202, 204, 301 i 302 oznaczają, że usługa działa, a każdy inny kod to awaria. Kody dodajesz i usuwasz osobno w każdym monitorze, np. 405 dla endpointu webhooków, który przyjmuje tylko POST.

Czy wdrożenie wywoła alerty?
Nie, jeśli zaplanujesz dla niego okno serwisowe w panelu albo z pipeline'u przez API AlertSleep. Sprawdzenia trwają dalej, ale alerty nie wychodzą, a okno nie obniża statystyki dostępności.

Czy mogę wypróbować monitoring API za darmo?
Tak, przez 14 dni. Nie ma darmowego planu, ale oba plany zaczynasz od 14-dniowego okresu próbnego z monitoringiem API, bez karty. Po okresie próbnym kosztuje od $59 rocznie. Jeśli chcesz raz sprawdzić pojedynczy endpoint, darmowy test czasu odpowiedzi nie wymaga konta.

Chcesz sprawdzić jeden endpoint od razu? Uruchom darmowy test czasu odpowiedzi

Zacznij monitorować swoje API już dziś

Pierwszy endpoint ustawisz w kilka minut. Wypróbuj za darmo przez 14 dni, bez karty.

Zacznij 14-dniowy okres próbny Zobacz Cennik