Dwa dni testów, analizowania błędów, sprawdzania konfiguracji serwerów, aktualizowania wtyczek i porównywania niezależnych instalacji WordPressa. W pewnym momencie rozważaliśmy nawet przeniesienie sklepów do innego dostawcy hostingu. Ostatecznie okazało się, że problemy ustępują po wyłączeniu CDN OVHcloud. Najbardziej rozczarowujące w całej historii jest jednak to, że rozwiązania nie wskazała pomoc techniczna dostawcy. Musieliśmy znaleźć je samodzielnie.
3 listopada 2026 roku – początek problemów z WooCommerce
Około 3 listopada 2026 roku zauważyliśmy poważne nieprawidłowości w działaniu kilku sklepów internetowych opartych na WordPressie i WooCommerce. Problem dotyczył dwóch niezależnych sklepów, które na potrzeby tego artykułu nazwiemy sklep-a.example.com oraz sklep-b.example.com, a także osobnej instalacji WooCommerce wykorzystywanej do obsługi magazynu.
Wszystkie problematyczne instalacje korzystały z usług hostingowych OVHcloud w pakiecie PERFORMANCE. Co ważne, sklepy znajdowały się na dwóch niezależnych usługach hostingowych, więc nie był to przypadek pojedynczej instalacji WordPressa.
Wcześniej wszystko działało prawidłowo. Nie wprowadzaliśmy zmian w konfiguracji stron ani serwerów, które mogłyby wyjaśnić nagłe pojawienie się problemów.
Początkowo podejrzewaliśmy błąd WordPressa, WooCommerce albo jednej z wtyczek odpowiedzialnych za komunikację między sklepami a magazynem. W końcu to właśnie aktualizacje, konflikty rozszerzeń i błędy konfiguracji należą do najczęstszych przyczyn problemów z popularnym systemem CMS.
Szybko jednak okazało się, że tym razem sytuacja wygląda inaczej.
WordPress zgłasza błąd REST API i cURL 28
Pierwszą konkretną wskazówkę znaleźliśmy w narzędziu „Kondycja witryny”, dostępnym w panelu administracyjnym WordPressa.
System informował o problemie z interfejsem REST API, który umożliwia komunikację między WordPressem, jego komponentami oraz innymi aplikacjami.
Przykładowy komunikat wyglądał następująco:
Adres REST API:
https://sklep-a.example.com/wp-json/wp/v2/types/post?context=edit
Odpowiedź REST API:
(http_request_failed) cURL error 28:
Connection timed out after 10000 milliseconds
Komunikat oznaczał, że żądanie HTTP nie otrzymało odpowiedzi w ciągu 10 sekund.
Sam błąd cURL 28 nie wskazuje jednoznacznie przyczyny. Może wynikać z problemów z siecią, DNS, firewallem, połączeniem HTTPS, serwerem docelowym lub infrastrukturą pośredniczącą w komunikacji.
W przypadku WordPressa ma to szczególne znaczenie, ponieważ niektóre mechanizmy REST API wykonują żądania do własnej domeny. Jeżeli połączenie zostaje zablokowane albo przekracza dopuszczalny czas oczekiwania, WordPress może zgłaszać błędy nawet wtedy, gdy strona główna normalnie otwiera się w przeglądarce.
Dla WooCommerce nie jest to błaha sprawa. Sklepy wykorzystują komunikację API między innymi do obsługi integracji, synchronizacji danych i różnych funkcji administracyjnych.
Aktualizacje WooCommerce nie przyniosły poprawy
Pierwszym krokiem było sprawdzenie aktualności oprogramowania.
Zweryfikowaliśmy WordPressa oraz zainstalowane wtyczki. Wykonaliśmy również aktualizację WooCommerce na instalacji magazynowej, licząc na to, że problem może wynikać z błędu konkretnej wersji.
Niestety, nic się nie zmieniło.
Magazyn nadal działał nieprawidłowo, a narzędzie „Kondycja witryny” wciąż zgłaszało problem z REST API.
Zaczęliśmy więc rozważać kolejne możliwe przyczyny: konflikt wtyczek, konfigurację PHP, ustawienia serwera, ograniczenia połączeń wychodzących oraz mechanizmy bezpieczeństwa hostingu.
Każdy z tych elementów mógł potencjalnie odpowiadać za błąd cURL 28.
Problem polegał na tym, że wszystkie te hipotezy wymagały czasu na weryfikację, a sklepy nadal nie działały tak, jak powinny.
Nowe instalacje WooCommerce również miały ten sam problem
Jednym z najważniejszych etapów diagnostyki było sprawdzenie całkowicie nowych instalacji WooCommerce.
Gdyby problem występował wyłącznie na jednym sklepie, można byłoby podejrzewać jego indywidualną konfigurację, historię aktualizacji albo konflikt wtyczek.
Tymczasem podobne błędy pojawiały się również na świeżych instalacjach.
To był bardzo ważny sygnał.
Trudno bowiem uznać za przypadek, że kilka niezależnych instalacji WooCommerce, w tym nowo utworzone, zaczyna zgłaszać podobne problemy z komunikacją API w tym samym okresie.
Dodatkowo awaria dotyczyła dwóch różnych usług hostingowych PERFORMANCE.
Coraz więcej wskazywało więc na wspólny element infrastruktury, a nie na wadliwą konfigurację pojedynczego sklepu.
Porównanie z innymi instalacjami WordPressa
Kolejnym krokiem było porównanie problematycznych sklepów z innymi stronami WordPress działającymi na naszych hostingach.
Nie wszystkie instalacje zgłaszały błędy.
Część witryn funkcjonowała całkowicie normalnie, co początkowo utrudniało postawienie jednoznacznej diagnozy.
Wśród prawidłowo działających stron znajdowały się instalacje bez aktywnej usługi CDN OVHcloud.
Z kolei wszystkie trzy problematyczne środowiska – dwa sklepy oraz magazyn – korzystały z CDN.
Początkowo była to jedynie obserwacja, a nie dowód. Jednak właśnie ona doprowadziła nas do pytania, które później okazało się kluczowe:
Czy źródłem problemów z REST API i WooCommerce może być CDN OVHcloud?
Pomoc techniczna OVHcloud – ogólne odpowiedzi zamiast konkretnej diagnostyki
W międzyczasie zgłosiliśmy problem do pomocy technicznej OVHcloud.
Opisaliśmy błędy cURL, nieprawidłowe działanie sklepów oraz fakt, że wcześniej wszystko funkcjonowało poprawnie.
Podkreśliliśmy również, że problem dotyczy dwóch niezależnych hostingów PERFORMANCE, a podobne błędy występują nawet na nowych instalacjach WooCommerce.
Odpowiedź wsparcia nie przyniosła jednak rozwiązania.
Pracownik pomocy technicznej wyjaśnił, że hosting współdzielony OVHcloud korzysta z zarządzanego firewalla, którego reguł klient nie może indywidualnie modyfikować. Wskazał również możliwość blokowania żądań przez firewall albo serwer docelowy.
Były to ogólne, technicznie możliwe przyczyny błędów cURL, ale odpowiedź nie wskazywała, co faktycznie dzieje się w naszym przypadku.
Nie otrzymaliśmy konkretnego wyniku analizy połączeń, wskazania blokowanego żądania ani potwierdzenia, że sprawdzono działanie infrastruktury CDN.
Co gorsza, zgłoszenie otrzymało status rozwiązania, mimo że sklepy nadal nie działały prawidłowo.
Z perspektywy klienta wyglądało to jak klasyczne odbijanie piłeczki. Zamiast rzeczywistej diagnostyki pojawiły się sugestie dotyczące konfiguracji aplikacji, firewalla i potencjalnych blokad po stronie serwera docelowego.
Oczywiście pomoc techniczna ma prawo podejrzewać błędną konfigurację klienta. Jednak kiedy problem występuje równocześnie na kilku instalacjach, w tym nowych, i na różnych usługach hostingowych, powinno to być sygnałem do pogłębionej diagnostyki.
Zamknięcie zgłoszenia nie oznacza przecież usunięcia awarii.
OVHcloud informowało o incydencie hostingowym 3 listopada
Podczas późniejszego sprawdzania historii awarii znaleźliśmy również interesującą informację na oficjalnej stronie statusowej OVHcloud.
3 listopada 2026 roku dostawca odnotował incydent dotyczący hostingu WWW w lokalizacji GRA. Zgłoszenie opisane jako „Some Filerz incident notification” wskazywało, że część witryn korzystających z określonych zasobów infrastruktury mogła być tymczasowo niedostępna.
Według opublikowanych informacji zdarzenie rozpoczęło się o godzinie 20:20 UTC i zakończyło o 21:05 UTC. Jako przyczynę wskazano problem programowy.
Nie mamy dowodu, że wspomniany incydent był bezpośrednio związany z naszymi problemami z CDN i REST API. Nie należy więc utożsamiać obu zdarzeń bez dodatkowych danych technicznych.
Sam fakt odnotowania problemów infrastrukturalnych w zbliżonym czasie jest jednak interesujący.
Pokazuje również, dlaczego pierwsza linia wsparcia powinna sprawdzać historię awarii i zmian infrastrukturalnych, zamiast ograniczać odpowiedź do ogólnych porad dotyczących WordPressa.
Wyłączenie firewalla OVHcloud niczego nie zmieniło
W toku diagnostyki wykonaliśmy również test polegający na wyłączeniu firewalla dostępnego w panelu OVHcloud dla jednego ze sklepów.
Chcieliśmy sprawdzić, czy żądania REST API są blokowane przez mechanizmy bezpieczeństwa hostingu.
Rezultat był jednoznaczny: żadnej poprawy.
Błąd cURL 28 nadal występował.
Test nie wykluczał wszystkich możliwych zabezpieczeń sieciowych OVHcloud, ponieważ firewall dostępny w panelu klienta nie musi być tożsamy ze wszystkimi mechanizmami filtrowania ruchu w infrastrukturze dostawcy.
Pozwalał jednak wyeliminować jedną z potencjalnych przyczyn i skierować uwagę na inne elementy środowiska.
WP-Optimize i pamięć podręczna – kolejny podejrzany
Na problematycznych sklepach wykorzystywaliśmy również WP-Optimize, popularną wtyczkę do optymalizacji WordPressa.
W pewnym momencie pojawiło się podejrzenie, że pamięć podręczna WP-Optimize może mieć związek z błędami.
Dodatkową trudnością było to, że panel administracyjny nie pozwalał normalnie wejść do ustawień cache.
Rozważaliśmy więc ręczne wyłączenie wtyczki przez FTP oraz usunięcie zawartości katalogu:
/wp-content/cache/wpo-cache/
Oczywiście z wcześniejszym wykonaniem kopii zapasowej.
Był to kolejny potencjalny kierunek diagnostyki, ale późniejsze testy pokazały, że nie trzeba było szukać przyczyny w cache WordPressa.
Co istotne, instalacja magazynowa miała wyłączony cache WP-Optimize, a mimo to również zgłaszała problemy z API.
To dodatkowo osłabiało hipotezę o winie tej wtyczki.
Przełom: wyłączenie CDN OVHcloud na magazynie
Po wielu godzinach analiz postanowiliśmy wykonać test, który ostatecznie okazał się decydujący.
Wyłączyliśmy usługę CDN OVHcloud na instalacji magazynowej.
Rezultat był natychmiastowy.
Magazyn zaczął ponownie działać prawidłowo.
Bez aktualizacji WooCommerce, bez zmian w kodzie WordPressa i bez przenoszenia strony na inny hosting.
To był moment przełomowy.
Skoro po wyłączeniu CDN problemy ustąpiły, uzyskaliśmy bardzo mocny dowód, że przyczyna jest związana z tą usługą lub sposobem obsługi ruchu przez jej infrastrukturę.
Pozostawało sprawdzić, czy identyczny rezultat uda się uzyskać na pozostałych sklepach.
Pierwszy sklep – wyłączenie CDN i niespodziewany błąd 520
Kolejnym krokiem było wyłączenie CDN OVHcloud na pierwszym sklepie.
Tutaj pojawił się jednak nowy problem.
Zamiast działającej witryny przeglądarka zaczęła wyświetlać:
Error 520 Domain not allowed on CDN
Guru Meditation
Varnish cache server
Na pierwszy rzut oka wyglądało to jak kolejna awaria.
W rzeczywistości komunikat dostarczył nam ważnej informacji: żądanie nadal docierało do infrastruktury CDN OVHcloud, mimo że obsługa domeny przez CDN została już wyłączona.
Nie był to komunikat WordPressa, WooCommerce ani WP-Optimize. Odpowiedź generowała warstwa Varnish.
Dlaczego tak się działo?
Po wyłączeniu CDN OVHcloud zmieniło adres IP domeny w strefie DNS. Część systemów nadal korzystała jednak z poprzedniego adresu zapamiętanego w pamięci DNS.
Powstała więc przejściowa sytuacja, w której CDN nie obsługiwał już domeny, ale niektóre urządzenia wciąż kierowały do niego żądania.
Sprawdzanie DNS i bezpośredniego adresu IP OVH
Weryfikacja DNS wykazała, że po wyłączeniu CDN domena pierwszego sklepu wskazywała na adres:
87.98.239.87
Był to bezpośredni adres hostingu OVHcloud, a nie adres usługi CDN.
Sprawdziliśmy również rekordy DNS za pomocą zewnętrznego narzędzia DNSCHECK.pl.
Nowy adres IP był już widoczny, a mimo to na części urządzeń nadal pojawiał się błąd 520.
To pokazuje istotną różnicę między zmianą rekordu DNS w panelu dostawcy a faktycznym rozpoczęciem korzystania z niego przez wszystkie urządzenia i serwery DNS.
Zmiana może być już widoczna w jednym miejscu, podczas gdy inny resolver nadal przechowuje wcześniejszy adres.
Po pewnym czasie pierwszy sklep zaczął ponownie działać, a problemy z funkcjonowaniem witryny ustąpiły.
Nie było potrzeby przenoszenia jej na inny serwer.
Drugi sklep – podobny problem, ale dłuższe oczekiwanie
Następnie wyłączyliśmy CDN na drugim sklepie.
Tutaj scenariusz był podobny, jednak proces przywracania dostępności trwał dłużej.
Ponownie pojawił się komunikat:
Error 520 Domain not allowed on CDN
W strefie DNS znajdowały się prawidłowe rekordy A dla domeny głównej i wariantu www, wskazujące na bezpośredni adres hostingu.
Dodatkowo domena posiadała rekordy AAAA obsługujące IPv6.
Weryfikacja wykazała, że wcześniejszy TTL części rekordów wynosił 21600 sekund, czyli aż sześć godzin.
Na czas diagnostyki zmniejszyliśmy TTL do 300 sekund, czyli pięciu minut.
Trzeba jednak pamiętać, że obniżenie TTL nie powoduje natychmiastowego usunięcia wcześniej zapamiętanych rekordów. Systemy, które pobrały stary adres z wcześniejszym TTL, mogą nadal korzystać z niego do czasu wygaśnięcia pamięci podręcznej.
Sytuacja była szczególnie interesująca, ponieważ drugi sklep zaczynał już działać na jednym laptopie, podczas gdy na innym komputerze i telefonie nadal wyświetlał błąd CDN.
Po kolejnych testach strona zaczęła działać również przez internet mobilny LTE.
To wskazywało, że przełączenie ruchu na bezpośredni serwer postępowało, a różne urządzenia i sieci nie korzystały jeszcze z tych samych aktualnych informacji DNS.
Ostatecznie również drugi sklep zaczął odzyskiwać prawidłowe działanie bez CDN.
Co wykazały dwa dni testów?
Najważniejsze obserwacje można podsumować w kilku punktach.
Po pierwsze: problem nie ograniczał się do jednego sklepu. Występował na kilku instalacjach WooCommerce, także nowych, oraz na dwóch niezależnych usługach hostingowych PERFORMANCE.
Po drugie: aktualizacje oprogramowania nie rozwiązały problemu. Nie pomogła między innymi aktualizacja WooCommerce na magazynie.
Po trzecie: wyłączenie firewalla dostępnego w panelu OVHcloud nie przyniosło poprawy.
Po czwarte: wszystkie problematyczne instalacje korzystały z CDN OVHcloud, podczas gdy porównywane działające instalacje nie korzystały z tej usługi.
Po piąte: wyłączenie CDN przywróciło prawidłowe działanie magazynu i pierwszego sklepu, a drugi sklep również zaczął funkcjonować po przełączeniu na bezpośredni hosting.
Ten ostatni punkt jest najważniejszy.
Nie mamy dostępu do wewnętrznych logów CDN OVHcloud, dlatego nie możemy wskazać konkretnej wadliwej reguły, serwera Varnish ani zmiany konfiguracji odpowiedzialnej za awarię.
Jednak powtarzalność problemu oraz rezultaty testów wyraźnie wskazują na CDN jako źródło nieprawidłowości w naszym środowisku.
Czy CDN OVHcloud jest potrzebny sklepom WooCommerce?
CDN, czyli Content Delivery Network, to technologia pozwalająca dostarczać zasoby stron internetowych za pośrednictwem rozproszonej infrastruktury serwerów.
W wielu przypadkach jest to korzystne rozwiązanie, szczególnie dla witryn obsługujących użytkowników z różnych krajów.
Jednak sklepy WooCommerce różnią się od prostych stron informacyjnych.
Duża część ich funkcjonalności opiera się na dynamicznej komunikacji z serwerem. Koszyk, proces zamówienia, sesje klientów, operacje administracyjne czy wybrane integracje wymagają prawidłowej obsługi żądań, których nie można traktować jak zwykłych statycznych plików.
Źle skonfigurowany lub wadliwie działający CDN może więc stać się dodatkowym punktem awarii.
W naszym przypadku po wyłączeniu CDN nie zauważyliśmy wyraźnego pogorszenia szybkości działania sklepów.
Witryny działały subiektywnie równie szybko jak wcześniej, a przy tym odzyskiwały prawidłową komunikację.
Nie oznacza to, że CDN jest rozwiązaniem niepotrzebnym. Oznacza jedynie, że w naszym środowisku jego dalsze wykorzystywanie przestało mieć uzasadnienie wobec zaobserwowanych problemów.
Polski adres IP po wyłączeniu CDN – czy ma znaczenie dla SEO?
Po rezygnacji z CDN sklepy zaczęły korzystać bezpośrednio z adresu IP hostingu OVHcloud.
W naszym przypadku był to adres przypisany do polskiej infrastruktury hostingowej.
W przypadku sklepów kierowanych przede wszystkim do klientów z Polski może to mieć pewne znaczenie techniczne, choć nie należy traktować samej lokalizacji IP jako gwarancji poprawy pozycji w Google.
Polska domena .pl, język treści, jakość witryny i jej rzeczywista użyteczność są znacznie ważniejszymi sygnałami rynku docelowego.
Adres IP i lokalizacja infrastruktury mogą natomiast wpływać na trasę połączenia, opóźnienia i wydajność, a więc pośrednio na doświadczenia użytkowników.
Największą korzyścią w naszym przypadku pozostaje jednak stabilność działania sklepu i poprawna komunikacja z API.
Dla SEO znacznie groźniejsza od braku CDN może być długotrwała niedostępność strony lub problemy techniczne utrudniające jej prawidłowe funkcjonowanie.
Największy problem? Nie sam CDN, lecz podejście pomocy technicznej
Awaria może zdarzyć się każdemu dostawcy hostingu.
Nawet największe firmy technologiczne nie są całkowicie odporne na problemy z oprogramowaniem, siecią czy infrastrukturą.
Od profesjonalnego dostawcy oczekujemy jednak czegoś więcej niż samego udostępnienia serwera.
Oczekujemy również kompetentnej diagnostyki, szczególnie gdy problem dotyczy kilku niezależnych instalacji i pojawia się nagle, bez zmian po stronie klienta.
W naszej ocenie obsługa OVHcloud nie sprostała temu zadaniu.
Zamiast konkretnej analizy otrzymaliśmy ogólne informacje o możliwych blokadach firewalla, połączeniach cURL i serwerach docelowych.
Nie przedstawiono nam technicznego potwierdzenia, że problem rzeczywiście leżał po stronie konfiguracji naszych sklepów.
Mimo to zgłoszenie zostało oznaczone jako rozwiązane.
Tymczasem klient przez dwa dni samodzielnie wykonywał kolejne testy, porównywał instalacje, sprawdzał DNS, analizował komunikaty błędów i próbował ustalić, który element infrastruktury powoduje nieprawidłowości.
Rozważaliśmy nawet migrację sklepów do innego dostawcy hostingu, ponieważ nie mieliśmy pewności, czy OVHcloud zajmie się problemem.
Ostatecznie wystarczyło wyłączyć CDN.
Czy naprawdę klient opłacający hosting PERFORMANCE powinien sam diagnozować działanie infrastruktury CDN swojego dostawcy?
Naszym zdaniem nie.
Jeżeli kilka instalacji WooCommerce zaczyna jednocześnie zgłaszać błędy REST API, a klient informuje, że problem pojawił się nagle i nie wprowadzał zmian, pomoc techniczna powinna przynajmniej sprawdzić możliwość występowania problemu po stronie usług sieciowych.
Tym bardziej że OVHcloud dysponuje własnymi systemami monitorowania infrastruktury i publikuje komunikaty dotyczące awarii.
Nie oczekujemy, że konsultant pierwszej linii będzie znał przyczynę każdego błędu. Oczekujemy natomiast, że w razie potrzeby przekaże zgłoszenie administratorom, którzy mogą wykonać rzeczywistą diagnostykę.
Rozwiązanie problemu nie oznacza naprawy CDN
Warto podkreślić jeszcze jedną rzecz.
Wyłączenie CDN rozwiązało nasze problemy operacyjne, ale nie oznacza, że OVHcloud naprawiło przyczynę awarii samej usługi CDN.
Nie otrzymaliśmy wyjaśnienia, co dokładnie przestało działać około 3 listopada.
Nie wiemy, czy problem wynikał z błędnej konfiguracji, aktualizacji infrastruktury, mechanizmu filtrowania żądań, komunikacji z serwerami źródłowymi czy innego elementu systemu.
Nie możemy również stwierdzić, czy podobne problemy wystąpiły u innych klientów korzystających z tej samej usługi.
Z perspektywy użytkownika najważniejszy jest jednak rezultat: po wyłączeniu CDN środowiska zaczęły ponownie funkcjonować prawidłowo.
To rozwiązanie praktyczne, ale nie zastępuje wyjaśnienia technicznej przyczyny problemu przez dostawcę.
Dwa dni stracone na problem, którego przyczyna leżała poza WordPressem
Cała sytuacja jest dobrym przykładem tego, jak trudna może być diagnostyka problemów z WordPressem i WooCommerce.
Początkowo wszystko wskazywało na błędy aplikacji.
Narzędzie „Kondycja witryny” zgłaszało cURL 28, REST API nie odpowiadało prawidłowo, a integracje sklepowe przestawały działać tak, jak powinny.
Sprawdzaliśmy aktualizacje, konfigurację, firewall, cache i zachowanie nowych instalacji.
Dopiero porównanie witryn działających z CDN i bez CDN pozwoliło znaleźć wspólny element.
Następnie prosty test wyłączenia CDN na magazynie przyniósł natychmiastowy rezultat.
Kolejne próby na dwóch sklepach potwierdziły ten kierunek, choć wymagały dodatkowego czasu na aktualizację DNS.
Przez dwa dni analizowaliśmy więc problem, którego źródło nie znajdowało się w samym WooCommerce.
Wnioski – czego nauczyła nas awaria CDN OVHcloud?
Najważniejszy wniosek jest prosty: nie każdy błąd WordPressa oznacza problem z WordPressem.
Jeżeli kilka niezależnych instalacji zaczyna zgłaszać podobne błędy w tym samym czasie, warto szukać wspólnego elementu infrastruktury.
Może nim być hosting, DNS, firewall, proxy, CDN albo inna usługa pośrednicząca w komunikacji.
Drugi wniosek dotyczy testowania zmian. Wyłączenie CDN może wymagać czasu na aktualizację DNS. Komunikat Domain pojawiający się bezpośrednio po przełączeniu nie musi oznaczać kolejnej awarii serwera WWW.
not allowed on CDN
Trzeci wniosek dotyczy jakości obsługi technicznej.
Dostawca hostingu nie powinien automatycznie zakładać, że winę ponosi klient. Szczególnie gdy przedstawione informacje wskazują na możliwość problemu infrastrukturalnego.
W naszym przypadku dwa dni testów doprowadziły do skutecznego praktycznego rozwiązania: wyłączenia CDN OVHcloud.
Magazyn odzyskał sprawność, a oba sklepy ponownie zaczęły działać po przełączeniu DNS na bezpośredni hosting.
Wszystko to bez konieczności migracji do innego dostawcy.
Pozostaje jednak pytanie, dlaczego klient musiał sam znaleźć przyczynę problemu, podczas gdy pomoc techniczna OVHcloud ograniczyła się do ogólnych wyjaśnień i próby zamknięcia zgłoszenia.
Bo awaria infrastruktury to jedno. Brak skutecznej pomocy w jej zdiagnozowaniu to zupełnie inny problem.
