Uptime jest jedną z tych liczb, które świetnie wyglądają w reklamie, a dużo gorzej w praktyce. „99,9%” brzmi jak pewność, ale w skali miesiąca to wciąż dziesiątki minut przerwy – i to pod warunkiem, że liczysz ją tak samo jak dostawca. Problem zaczyna się wtedy, gdy Ty widzisz „strona nie działa”, a hosting mówi: „u nas było OK, to Twoja aplikacja”.
Drugie źródło rozczarowań to SLA. Wiele osób traktuje SLA jak gwarancję „nie będzie awarii”, a w umowach SLA częściej oznacza: „jak spełnisz warunki, to dostaniesz niewielki rabat”. Do tego dochodzą wyjątki: okna serwisowe, awarie „poza kontrolą”, problemy z DNS, a czasem nawet brak liczenia krótkich przerw.
Trzeci kłopot jest bardziej podstępny: degradacja zamiast twardego „down”. Strona formalnie odpowiada, ale ładuje się 25 sekund albo sypie błędami 500 co któryś request. Z perspektywy użytkownika (i sprzedaży) to często gorsze niż 5-minutowa przerwa, bo rozwleka się godzinami.
Da się to ogarnąć bez kupowania „premium” tylko dlatego, że marketing krzyczy najgłośniej. Klucz to: (1) wiedzieć, co dokładnie jest mierzone, (2) mierzyć to niezależnie, (3) umieć zebrać dowód i rozliczyć SLA, (4) odróżniać awarię hostingu od problemu aplikacji.
W tym artykule dostajesz praktyczny zestaw: jak czytać SLA, jaki monitoring ustawić (zewnętrzny i „od środka”), jak interpretować wyniki, jak zgłosić naruszenie SLA i kiedy dopłata ma sens – a kiedy płacisz wyłącznie za ładny slajd w ofercie.
Co naprawdę oznacza uptime i dlaczego „99,9%” może uśpić Twoją czujność
Uptime to procent czasu, w którym usługa jest „dostępna”. Brzmi prosto, ale diabeł tkwi definicji dostępności. Dla jednych to: „serwer odpowiada na ping/HTTP”. Dla innych: „aplikacja zwraca poprawną stronę i da się złożyć zamówienie”. W SLA niemal zawsze spotkasz tę pierwszą, wąską wersję – i to jest ważne, bo z Twojej perspektywy liczy się ta druga.
Warto przeliczać procenty na realny czas. 99,9% w miesiącu to około 43 minuty niedostępności. 99,5% to już kilka godzin. A jeżeli dostawca liczy dostępność w skali roku, to krótkie awarie mogą „zgubić się” w średniej, mimo że akurat trafiły Cię w kampanię albo w weekend z największą sprzedażą.
Druga pułapka: okna serwisowe i „wyłączenia odpowiedzialności”. Jeśli SLA wycina z liczenia planowane prace, awarie sieci upstream, problemy DNS albo „błędy aplikacji”, to procent przestaje być porównywalny między firmami. Dwie oferty z „99,9%” mogą realnie oznaczać zupełnie inny poziom ryzyka.
Trzecia sprawa to różnica między hostingiem WWW, WordPress i e-commerce. WordPress i PrestaShop częściej „wykładają się” w sposób miękki: strona odpowiada, ale jest nieużywalna (czas ładowania, błędy 500, timeouty do bazy). Jeśli rozważasz środowisko pod WP, porównuj nie tylko uptime, ale też jakość procesu utrzymaniowego.
Na koniec: uptime to nie tylko awarie. To też to, jak szybko dowiesz się o problemie i jak szybko ktoś go naprawi. Dwa hostingi mogą mieć podobny procent, ale w jednym awaria trwa 6 minut i jest od razu ogarnięta, a w drugim 2 godziny i dowiadujesz się z wiadomości od klienta.
SLA bez magii: co weryfikować w umowie, zanim uwierzysz w procenty
Zacznij od tego, co dokładnie jest objęte SLA. Szukasz odpowiedzi na trzy pytania: co mierzą, jak mierzą i kiedy nie liczą. W dobrym SLA znajdziesz definicję „niedostępności” (np. brak odpowiedzi na HTTP z konkretnych punktów pomiaru) oraz informację, czy liczą „degradację” (np. duży czas odpowiedzi) czy tylko „twardy down”.
Następnie sprawdź okres rozliczeniowy. Miesiąc jest dla klienta bardziej sensowny niż rok, bo awaria w złym momencie ma realny koszt tu i teraz. Zwróć uwagę, czy SLA dotyczy całej usługi, czy tylko infrastruktury (serwer działa, ale Twój panel/FTP/poczta już niekoniecznie). Częsty haczyk: SLA obejmuje „warstwę sieciową”, a nie obejmuje np. działania PHP czy bazy danych – a to właśnie one są źródłem większości problemów w praktyce.
Kolejny punkt to warunki uzyskania rekompensaty. W wielu regulaminach musisz zgłosić awarię w konkretnym czasie i dostarczyć dowody. Zdarza się też, że dostawca wymaga, abyś korzystał z ich kanału monitoringu albo aby incydent był potwierdzony przez ich systemy. To nie jest złe samo w sobie, ale musisz wiedzieć, czy Twoje pomiary będą uznane.
Sprawdź też, jak wygląda „kasa” w SLA. Najczęściej nie dostajesz zwrotu proporcjonalnego do straty, tylko kredyt/rabat na kolejny okres (często niewielki). Jeśli Twoim celem jest minimalizacja kosztu biznesowego, to SLA jest tylko jednym z elementów – resztę dowozisz procesem: monitoring, automatyczne przełączenia, cache, plan komunikacji. Jeżeli jesteś na etapie wyboru usługi, podejdź do tego tak, jak do całego zestawu kryteriów – dla ułatwienia przeczytaj nasz wpis jak wybrać hosting.
Monitoring z zewnątrz: jak mierzyć dostępność tak, jak widzi ją klient
Najbardziej uczciwy monitoring to taki, który patrzy na Twoją stronę z internetu, a nie z wnętrza serwerowni hostingu. Klient nie obchodzi, że „serwer odpowiada na ping”, jeśli strona nie otwiera się w przeglądarce. Dlatego podstawą jest monitoring HTTP/HTTPS: cykliczne żądanie do konkretnego URL i oczekiwanie poprawnej odpowiedzi.
Pierwsza decyzja: co monitorujesz. Minimum to strona główna, ale często lepiej jest monitorować „lekki” endpoint, który nie zależy od ciężkich elementów (np. /health lub prostą podstronę bez zewnętrznych integracji). Jeśli nie masz własnego healthchecka, monitoruj stronę, która najpewniej działa stale (np. /kontakt), ale uważaj na cache i mechanizmy ochrony (WAF, anty-bot), które potrafią blokować monitor „fałszywie”.
Druga decyzja: z ilu lokalizacji. Pojedynczy punkt pomiaru potrafi oszukać: awaria routingu między monitoringiem a serwerem wygląda jak „down”, mimo że klienci z Polski wchodzą normalnie (albo odwrotnie). Ustaw co najmniej 2–3 lokalizacje w Europie i jedną „z boku” (np. USA), żeby szybciej odróżnić problem lokalny od globalnego.
Trzecia decyzja: interwał i progi. 60 sekund jest OK dla większości stron. Jeżeli mierzysz co 5 minut, to możesz przegapić krótkie, ale częste przerwy, które rozwalają koszyk zakupowy. Do tego dodaj alerty: e-mail + powiadomienie na telefon i sensowną agregację (np. alarm dopiero po 2–3 kolejnych błędach), żeby nie dostać 30 fałszywych alarmów w nocy.
Jedna praktyczna rzecz, która robi różnicę: oprócz „czy działa”, mierz też czas odpowiedzi. Strona, która odpowiada po 12 sekundach, z perspektywy użytkownika często „nie działa”, choć monitoring uptime pokaże 100%. Tę różnicę widać szczególnie w WordPressie, gdzie dochodzą wtyczki, cron i zewnętrzne API.
Monitoring od środka: logi, healthcheck i sygnały, że „to nie hosting”
Zewnętrzny monitoring mówi Ci „co widzi klient”. Monitoring od środka mówi „dlaczego”. Najprościej: logi HTTP, logi aplikacji i statusy usług (PHP-FPM, baza danych, cache). Jeżeli masz VPS/dedyk, dochodzi monitoring zasobów, ale nawet na współdzielonym hostingu zwykle masz choć częściowy wgląd w logi i statystyki.
Pierwszy filar to logi serwera WWW: błędy 5xx, 4xx, timeouty, przekroczenia limitów. Jeśli w czasie alarmu widzisz lawinę 504/502, to nie jest „chwilowy kaprys internetu” — to konkretna wskazówka, że backend nie wyrabia. Jeśli z kolei jest mnóstwo 403/429, to być może problemem jest ochrona anty-bot/WAF albo limit zapytań, a nie sama dostępność serwera.
Drugi filar to zdrowie aplikacji. Dla WordPressa typowe symptomy to: zawieszające się admin-ajax, długie zapytania do bazy, cron uruchamiający ciężkie zadania w złym momencie. Dla PrestaShop często dochodzą integracje (płatności, ERP) i indeksowanie. Jeśli prowadzisz sklep, rozważ oddzielny monitoring ścieżki zakupowej (np. czy da się dodać do koszyka i przejść do checkoutu) – to bardziej „biznesowe” niż ping.
Trzeci filar to monitoring DNS i certyfikatu. Klientowi jest wszystko jedno, że serwer działa, jeśli domena nie działa albo certyfikat wygasł. Co ważne: część SLA wprost wyłącza DNS z odpowiedzialności, więc to Ty musisz to kontrolować. Ustaw osobny check na rekordy DNS (z kilku lokalizacji) oraz alarm na termin ważności certyfikatu.
Jeśli jesteś na etapie budowania kryteriów „co ma mieć dobry dostawca”, to spójrz na temat bardziej całościowo – nie tylko uptime, ale też narzędzia, wsparcie i przewidywalność. Dobrze to porządkuje nasz przewodnik najlepszy hosting, bo pokazuje, co realnie odróżnia solidną usługę od ładnych obietnic.
Downtime vs „strona muli”: jak odróżnić awarię od degradacji i co mierzyć
W praktyce najwięcej szkód robi degradacja. Strona odpowiada, ale wolno. Klienci klikają „odśwież”, rośnie liczba zapytań, robi się spirala i w końcu jest prawdziwy down. Jeśli mierzysz tylko „czy działa”, zobaczysz to za późno i będziesz się spierać z hostingiem, że „przecież było 200 OK”.
Dlatego potrzebujesz dwóch osi pomiaru: dostępności (statusy) i jakości (czas odpowiedzi, error rate). Ustal progi, które są „już problemem”, np. median > 1,5 s, p95 > 3-4 s, albo error rate > 1-2% w oknie 5-10 minut. Nie musisz robić z tego SRE w korpo – chodzi o to, żeby mieć definicję „to już wpływa na użytkownika”.
Kiedy pojawia się problem, patrz na korelacje: czy wzrosła liczba 500/502/504, czy czas odpowiedzi rośnie stopniowo, czy problem dotyczy tylko jednej lokalizacji, czy wszystkich. Jeśli tylko jednej, to często routing; jeśli wszystkich, to backend. Jeśli rośnie stopniowo, to może to być zapełniający się zasób (pamięć, limity procesów, baza), a jeśli jest „zero-jedynkowo”, to częściej awaria usługi lub deploy.
Warto też rozdzielić „front” od „zaplecza”. Czasem strona główna jest z cache i działa, ale panel logowania, koszyk albo API już nie. Dlatego dla serwisów sprzedażowych monitoruj przynajmniej dwa endpointy: jeden cache’owalny i jeden „dynamiczny”. Wtedy szybciej udowodnisz, że problem nie leży po stronie Twojego dostawcy DNS ani po stronie użytkownika, tylko w warstwie aplikacyjnej/serwerowej.
Jeśli Twoja strona jest mocno zależna od wyszukiwarki i ruchu organicznego, degradacja ma jeszcze jeden skutek uboczny: gorsze wrażenia użytkownika i sygnały jakości.
Porównywanie ofert bez przepłacania: pytania, które obnażają marketing
Jeśli dostawca krzyczy „99,99%”, poproś o dwie rzeczy: definicję niedostępności i historyczne raporty. Nie muszą podawać szczegółów infrastruktury, ale powinni umieć pokazać, jak raportują incydenty i jak wygląda komunikacja (status page, powiadomienia, post-mortem). Brak transparentności często oznacza, że będziesz się dowiadywać o awarii od klientów.
Drugie pytanie: jak rozliczają SLA w praktyce. Czy naliczają automatycznie, czy musisz składać wniosek. Czy liczą krótkie przerwy. Czy liczą degradację. Jakie są wyłączenia (DNS, certyfikaty, ataki DDoS, awarie upstream). Jeśli odpowiedzi są „ogólne”, poproś o fragment regulaminu. Na tym etapie łatwo odsiać oferty, które żyją wyłącznie hasłem.
Trzecie pytanie: jak wygląda wsparcie podczas incydentu. Nie chodzi o „czy jest 24/7”, tylko o proces: kanał zgłoszeń, czas reakcji, eskalacja, komunikacja. Jeśli hosting ma status page i publikuje aktualizacje co 15–30 minut w trakcie awarii, to jest sygnał dojrzałości. Jeśli jedyne, co dostaniesz, to „prosimy czekać”, to procent uptime traci znaczenie.
Czwarte pytanie: co jest w cenie, a co jest dopłatą. Czasem dopłata do „wyższego pakietu” to głównie marketingowe dodatki, a nie realna poprawa niezawodności. Z drugiej strony bywają dopłaty sensowne (oddzielna pula zasobów, lepsza izolacja, HA). Żeby nie błądzić po ciemku, zestawiaj oferty w kontekście realnych scenariuszy: awaria bazy, przeciążenie PHP, problem z siecią, błędna aktualizacja.
Jeżeli potrzebujesz punktu odniesienia do porównań (i chcesz zacząć od szerokiego przeglądu), możesz podejrzeć Ranking hostingów. Nie jako „wyrocznię”, tylko jako mapę rynku, na której łatwiej ułożyć shortlistę i dopiero wtedy weryfikować SLA i procesy.
Jak egzekwować SLA: dokumentacja, wyliczenia i zgłoszenie krok po kroku
SLA da się egzekwować tylko wtedy, gdy masz dowód. Najlepszy dowód to: log z zewnętrznego monitoringu + potwierdzenie z kilku lokalizacji + zrzut statusów HTTP i czasów odpowiedzi. Jeśli monitoring pokazuje „down”, dopisz kontekst: od kiedy do kiedy, jakie endpointy, jakie kody odpowiedzi, czy problem dotyczył też DNS.
Krok pierwszy: odseparuj problem aplikacji od infrastruktury. Jeżeli masz dostęp do logów, sprawdź, czy w czasie alarmu rosną błędy 5xx, timeouty, błędy połączenia do bazy. Jeżeli nie masz logów, zrób chociaż „triangulację”: otwórz stronę z telefonu (LTE) i z sieci Wi-Fi, a do tego sprawdź z narzędzia typu „curl” (lub prostego testu online) – chodzi o to, by wykluczyć lokalną awarię internetu.
Krok drugi: policz czas niedostępności w sposób zgodny z SLA. Jeżeli SLA liczy „niedostępność = brak odpowiedzi na HTTP przez X minut”, to nie wpisuj „od 12:03 do 12:07 nic mi się nie otwierało”, tylko pokaż serię pomiarów. Jeśli masz interwał 60 s, to pokaż 4–5 kolejnych błędów. Jeżeli SLA liczy degradację, pokaż, że czas odpowiedzi przekraczał próg przez określony czas.
Krok trzeci: złóż zgłoszenie tak, żeby od razu dało się je rozliczyć. W treści ticketu umieść: datę i godzinę, zakres czasu, adresy URL, wyniki z monitoringu, lokalizacje pomiaru, kody odpowiedzi, informację, czy problem dotyczył też panelu/FTP/poczty (jeśli tak). Im mniej „emocji”, a więcej danych, tym mniej odbijania piłeczki.
Krok czwarty: domknij temat po incydencie. Poproś o krótkie wyjaśnienie przyczyny (choćby ogólne) i działania zapobiegawcze. Nawet jeśli rekompensata jest symboliczna, wnioski są bezcenne: czy potrzebujesz dodatkowego monitoringu, czy warto rozdzielić usługi (DNS osobno), czy trzeba zmienić harmonogram aktualizacji.
Najczęstsze błędy i jak je naprawić
Najczęstszy błąd to ślepa wiara w procent z oferty. Jeśli nie wiesz, co dokładnie jest mierzone, to nie masz z czego się rozliczać. Naprawa: poproś o definicję „niedostępności” z umowy i dopasuj do niej własny monitoring (albo przynajmniej sprawdź, czy monitorujesz to samo, co dostawca).
Drugi błąd to monitoring tylko z jednej lokalizacji. Pojedynczy punkt pomiaru potrafi generować fałszywe alarmy (problem po drodze) albo nie widzieć realnej awarii (problem regionalny). Naprawa: ustaw minimum 3 lokalizacje i alert dopiero po potwierdzeniu w co najmniej dwóch z nich. Wtedy szybciej odróżnisz awarię hostingu od „dziury” w routingu.
Trzeci błąd to mierzenie wyłącznie „200 OK”. Strona może zwracać 200, a jednocześnie być praktycznie nieużywalna (czas odpowiedzi, zrywanie zasobów, błędy w koszyku). Naprawa: dodaj pomiar czasu odpowiedzi i osobny check na endpoint dynamiczny (np. logowanie, koszyk, API), a nie tylko stronę główną z cache.
Czwarty błąd to brak monitoringu DNS i certyfikatu. Część awarii „hostingu” w oczach klienta to w praktyce DNS (rozwiązanie domeny) albo wygasły certyfikat. Naprawa: osobne alerty: (1) rozwiązywanie domeny z kilku lokalizacji, (2) data ważności certyfikatu, (3) ewentualnie monitor zmian rekordów (jeśli często migrujesz).
Piąty błąd to zgłoszenia bez danych. „Nie działa” jest prawdziwe, ale nie jest rozliczalne. W efekcie ticket trwa długo, a SLA przepada, bo minął termin zgłoszenia albo „nie da się potwierdzić”. Naprawa: przygotuj szablon incydentu (czas, URL, kody, lokalizacje, screeny/wykresy) i trzymaj go w jednym miejscu. To skraca czas reakcji i zwiększa szansę na uznanie reklamacji.
Szósty błąd to mylenie problemów aplikacji z awarią hostingu – szczególnie w WordPressie (wtyczki, cron, zapytania do bazy). Naprawa: podczas incydentu sprawdzaj logi i błędy 5xx oraz testuj „lekki” endpoint.
Uptime a SEO i pieniądze: kiedy dopłacić, a kiedy zoptymalizować proces
Z perspektywy biznesowej uptime to nie „czy kiedykolwiek padnie”, tylko „ile kosztuje minuta problemu i jak często się zdarza”. Jeśli masz stronę-wizytówkę, 40 minut przestoju w miesiącu może przejść bez echa. Jeśli masz e-commerce, 15 minut w piku kampanii potrafi zjeść budżet reklamowy i narobić szkód w obsłudze klienta.
Ustal sobie prosty model: ile średnio zarabiasz na godzinę i ile kosztuje Cię utrata leadów/zamówień + koszt wsparcia (telefony, maile, reklamacje). Do tego dodaj koszt wizerunkowy (klienci, którzy nie wrócą). Z tym modelem łatwiej ocenić, czy dopłata 30-100 zł/mies. ma sens, czy lepiej zainwestować w monitoring, cache, CDN i proces aktualizacji.
SEO jest tu „efektem ubocznym”, ale realnym. Przestoje i częste błędy serwera potrafią utrudniać crawl i psuć doświadczenie użytkownika, a degradacja ładowania wpływa na zachowanie odwiedzających.
Kiedy dopłata ma sens? Zwykle wtedy, gdy dostajesz coś konkretnego: lepszą izolację zasobów, jasny proces incydentowy, transparentną komunikację, możliwość skalowania i realne wsparcie. Kiedy nie ma sensu? Gdy płacisz za „wyższy uptime” bez zmiany definicji SLA, bez lepszej reakcji, bez narzędzi i bez historii raportów.
FAQ – Najczęściej zadawane pytania
To zależy od tego, jak to liczyć i co dla Ciebie znaczy „działa”. W ujęciu miesięcznym 99,9% to ok. 43 minuty niedostępności. To może być akceptowalne dla strony firmowej, ale dla sklepu w sezonie bywa bolesne. Kluczowe jest też, czy dostawca liczy tylko „twardy down” (brak odpowiedzi), czy uwzględnia degradację (bardzo wolne odpowiedzi, masowe błędy 5xx). Dwie oferty z tym samym procentem mogą dawać zupełnie inne doświadczenie użytkownika.
Potrzebujesz niezależnego monitoringu HTTP/HTTPS (z kilku lokalizacji) oraz zasad liczenia zgodnych z definicją w SLA. Zbieraj dane: czas, kody odpowiedzi, czas odpowiedzi, potwierdzenie z więcej niż jednego punktu pomiaru. Jeśli SLA wyklucza DNS, ustaw osobny monitoring DNS – inaczej „awaria strony” może nie zostać uznana, bo hosting powie, że serwer działał.
Najlepiej oba, ale jeśli masz wybrać jedno, endpoint /health jest zwykle stabilniejszy i szybciej odróżnia problem backendu od problemu z frontem (np. zewnętrzne skrypty, ciężkie elementy). Strona główna bywa cache’owana i może ukryć problemy koszyka/logowania. Dla sklepów sensownie jest dodać monitoring „biznesowy” (np. dodanie do koszyka albo wejście w checkout), bo to najważniejsza ścieżka.
Często tak, jeśli ustawisz je mądrze: kilka lokalizacji, interwał 60 sekund, alarm po 2-3 kolejnych błędach, a do tego pomiar czasu odpowiedzi. Płatne plany zwykle dają lepsze raporty, więcej lokalizacji, integracje i dłuższą retencję danych, co pomaga w sporach o SLA. Na start ważniejsza jest poprawna konfiguracja niż „premium”.
Najczęstsze powody to problem po drodze (routing), blokada przez WAF/anty-bot, problem DNS albo zbyt wąska definicja SLA (hosting mierzy ping/port, a Ty mierzysz realną stronę). Dlatego warto mieć kilka lokalizacji monitoringu i dodatkowy test DNS. W sporze pomagają też logi oraz informacja, czy problem dotyczył wielu sieci (np. LTE i Wi-Fi).
Zależy od SLA. Wiele umów liczy tylko brak odpowiedzi, a nie „wolno”. Z perspektywy użytkownika wolno często znaczy „nie działa”, ale formalnie może nie być podstawy do rekompensaty. Rozwiązaniem jest mierzenie czasu odpowiedzi i traktowanie degradacji jako osobnego incydentu operacyjnego: analizujesz logi, obciążenie, zapytania do bazy i wtyczki, zamiast opierać się wyłącznie na procentach.
Zrób zestaw dowodów: raport z monitoringu (czas od–do), potwierdzenie z co najmniej dwóch lokalizacji, lista statusów HTTP, ewentualnie screen wykresu czasu odpowiedzi. Dobrze działa też dodatkowy ślad: wynik zapytania DNS w czasie incydentu oraz krótki opis objawów (np. 502/504). W zgłoszeniu trzymaj się faktów i definicji z SLA – to przyspiesza uznanie.
W praktyce oba, ale czas reakcji często decyduje o realnym koszcie incydentu. Dwie usługi z podobnym uptime mogą różnić się tym, czy awaria trwa 10 minut czy 2 godziny. Patrz na proces: kanał zgłoszeń, eskalacja, komunikacja w trakcie incydentu. Uptime bez sensownej obsługi incydentów potrafi być „ładną średnią” bez wartości w krytycznym momencie.
Wtedy, gdy dopłata daje konkret: lepszą izolację zasobów, wyższy standard utrzymania, transparentność incydentów, jasne SLA i realne wsparcie. Jeśli dopłata zmienia tylko „liczbę w ulotce” bez zmiany definicji SLA i bez poprawy procesu, to zwykle przepłacasz za marketing. Zanim dopłacisz, policz koszt godziny przestoju w Twoim biznesie i porównaj z kosztem usprawnień po Twojej stronie (monitoring, cache, optymalizacja aplikacji).
30-letnia pasjonatka informatyki, która świat serwerów i hostingów zna od podszewki. Wierzy, że technologia powinna ułatwiać życie, a nie je komplikować. Żyje w ciągłym ruchu – jeśli akurat nie konfiguruje nowej usługi, prawdopodobnie pakuje plecak na kolejną wyprawę w nieznane.
Dodaj komentarz